sqlgrey-users

[Sqlgrey-users] Working on SQLgrey

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

Just a quick line.

I commited some changes in the 1.7.x branch:
- SQLgrey now optionally cache prepared statements (by default it no
longer does). This is an attempt to workaround the memory leaks that
occur with some DBI/DBD versions. People looking for the best
performance will have to use db_prepare_cache = 1 in the configuration file.
- Added "Reuse => 1". This should allow SQLgrey to restart more quickly.
- Removed a warning log message when there's no entry in the config
table (this occurs when we look for the db_last_cleanup entry for the
first time).

Lionel, now going after the syslog-related crash.

Re: [Sqlgrey-users] Working on SQLgrey

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

Lionel Bouton wrote the following on 04.02.2007 20:32 :
> Just a quick line.
>
> I commited some changes in the 1.7.x branch:
> - SQLgrey now optionally cache prepared statements (by default it no
> longer does). This is an attempt to workaround the memory leaks that
> occur with some DBI/DBD versions. People looking for the best
> performance will have to use db_prepare_cache = 1 in the configuration file.
> - Added "Reuse => 1". This should allow SQLgrey to restart more quickly.
> - Removed a warning log message when there's no entry in the config
> table (this occurs when we look for the db_last_cleanup entry for the
> first time).
>
> Lionel, now going after the syslog-related crash.
>   

Syslog related crashes are fixed in CVS (I went the "eval" way for the
curious). There is only one last problem : SQLgrey can't start if syslog
doesn't work (nothing much to do here I believe). It only support syslog
being shutdown during operation. This should take care of the problems
people reported though.

This is in the 1.7.x branch. 1.6 backport and a 1.6.8 release will
follow later.

Lionel

Re: [Sqlgrey-users] Working on SQLgrey

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

Lionel Bouton wrote the following on 04.02.2007 22:11 :
> Syslog related crashes are fixed in CVS (I went the "eval" way for the
> curious). There is only one last problem : SQLgrey can't start if syslog
> doesn't work (nothing much to do here I believe).

Surprisingly it starts. I'm not sure it will connect to the daemon
afterwards though. You may have to restart SQLgrey to enable logging.
People willing to use CVS code are welcomed to comment on the results
they get.

Lionel

Re: [Sqlgrey-users] Working on SQLgrey

[Kenneth M. <kt...@ri...>]

Lionel,

Do you have an idea as to what would be the best choice of a primary
key for the connect table? All the other tables have one, and without
it Slony1 replication will not work. The two more obvious choices would
be to add an ID column with a default value from a sequence or to use
a unique index on src, sender_domain, sender_name, rcpt. 

Ken Marshall

Re: [Sqlgrey-users] Working on SQLgrey

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

Kenneth Marshall wrote the following on 27.02.2007 22:58 :
> Lionel,
>
> Do you have an idea as to what would be the best choice of a primary
> key for the connect table? All the other tables have one, and without
> it Slony1 replication will not work. The two more obvious choices would
> be to add an ID column with a default value from a sequence or to use
> a unique index on src, sender_domain, sender_name, rcpt.

The unique index is ok. I couldn't add it because MySQL didn't support
indexes for large columns (from memory the total size of the columns
must be less than ~500 chars).

PostgreSQL is OK with it so you can add it. Pay attention to future
schema migrations: your schema will be customized and if SQLgrey tries
to convert the connect table to another format you will lose your index
(as I didn't looked much into Slony1 I'm not sure that it would even
support the replication of a database on which the schema changes...).

Lionel.