Re: [Sqlgrey-users] 1.7.4 warnings

[Lionel B. <lio...@bo...>]

Dan Faerch wrote the following on 20.01.2007 21:38 :
> Lionel Bouton wrote:
>   
>> I did get these warnings and now they disappeared, so WorksForMe(tm).
>>   
>>     
> Great, thanks for testing. Ill commit it to CVS then.. Since i dont feel 
> such a small change warrents a new release, ill see if i can find time 
> to look at some of the issues/feature requests, reported on the tracker 
> (no garantees though). Especially:
>
> [ 1613916 ] sqlgrey 1.6.7 dies if syslog daemon is down
> - I've confirmed this on our setup. I think its a serious problem.
>
>   

Agreed. I'm leaving for holidays, but as soon as I have some time
(probably around january the 31th) I'll issue a 1.6.8 with a fix for
this one.

> [ 1574884 ] db_clean_hostname and HOSTNAME
> - Non critical problem, but its not doing excacttly what its supposed 
> to. Im thinking about maybe redesigning the way this works so you can 
> disable automatic db-clean entirely, and THEN run it as cronjob from one 
> host. Eg. 'sqlgrey --db-clean'.
>   

If I were you, I'd store the last cleanup timestamp in the database.
SQLgrey would maintain a local cache of the value stored in the DB (to
avoid asking it on each mail). Then, when an instance of SQLgrey would
find that the cleanup is due according to its local cache it would begin
by verifying that its local cache is up to date (if not it replaces the
cache value and tests it again). If the cleanup is indeed due, it would
update the value in DB and then call the cleanup procedure -> zero conf
needed (I like avoiding configuration, software should just work given
the bare minimum information even if it means more work for the developer).

You could have race conditions where 2+ SQLgrey wants to update at the
very same time. This is probably not a problem as:
- it should be very rare,
- it can only marginally slow down the database, not corrupt it in any way,
- each SQLgrey instance won't notice any problem and everybody will
continue happily.

There's even a solution using serializable transactions to make sure
that only one SQLgrey instance will trigger the cleanup if you have a
transactional DBMS (PostgreSQL or MySQL with InnoDB, probably 5.x for
serializable transactions).

As a positive side-effect, SQLgrey can stop cleaning the database each
time it is started...

> [ 1580029 ] MX and SPF checking
> - SPF checking would be really cool :). Anyone who knows which spf-lib 
> for perl is the "standard"?
>   

Hum, you do what you want with 1.7.x, but I'm considering SPF as a dying
horse begging for someone to put an end to its misery... Any DNS query
is a problem with SQLgrey as the process serializes Postfix requests. MX
checking would be interesting but you'll have to solve the serialization
problem.

Lionel.