Re: [Sqlgrey-users] 1.7.4 warnings

[Dan F. <da...@ha...>]

Lionel Bouton wrote:
>> Like this:
>> SELECT.
>>   
>>     
>
> I don't really understand what you meant with this SELECT.
>
>   
Select * from whatever WHERE last_cleanup < sumthing-sumthing.
You need to select the last cleanup time, to be able to compare if 
another sqlgrey already did it.
>> Determine if its time to do clean up..
>> If yes -> sleep random(0-x)
>> UPDATE (blahblah) WHERE `timestamp`='<timestamp from SELECT>'
>> If affected_rows > 0 then do_cleanup.
>>
>>   
>>     
>
> Hum I forgot about this method. But why sleep? Assuming you have the
> expected timestamp at which you think you should cleanup (the cached
> value I spoke of) :
> UPDATE <table> SET timestamp = expected where timestamp < expected.
>
> And as you pointed out, the number of affected rows tells us if we are
> responsible for the cleanup:
> - 0: no someone else managed to modify the timestamp just before us
> (just update the "expected" cache)
> - 1: yes we are the one ! update the "expected" cache and cleanup.
>
> No need to sleep, no two clients can really update the same row given
>   
Youre right.. Didnt think of that. I wrote it because i usually SELECT 
twice. SELECT 1. Do some math or whatever, SLEEP random and SELECT 2, to 
make sure noone has already changed this.

But i guess i need to know if "affected rows" work on all sql's?

> processes or threads (which probably better explains my comments on DNS
> queries).
>
>   
It does explain it, yes..

> SPF breaks email forwarding (SRS is a solution but _all_ forwarding
> mailservers should support it in order for it to work properly), only
> tells you that the server is authorized for a domain and not if it wants
> to send SPAM and is so poorly understood that it breaks email in many
> places (I've seen anti-SPAM appliances/proprietary software which
> checked the From header instead of the Return-path for example...).
>   
Im still not convinced its a bad idea.. But ill give it some more though 
before rushing into it..


- Dan