Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Rupa S. (lists) <rup...@ru...>]

On 7/25/2005 12:19 PM, Lionel Bouton wrote:
> You are the first one to report this bug with "clean_method = sync".
> This is *odd*. I need to be absolutely sure about that: please make sure
> that there's no older sqlgrey version lying around (only 1.6.4 uses the
> clean_method entry correctly).

bummer. :(  Just did a diff against the expanded 1.6.4 tar and it is the
same.

> 
> If this is the case then there probably is a bug in the DBI/DBD layer
> according to the following line you sent in your other mail:
> 
> Jul 25 10:18:43 shakti sqlgrey: dbaccess: error: couldn't get reconnect
> delay: ERROR:  prepared statement "dbdpg_282" does not exist

This isn't consistent with a freeze though.  Just noticed it while
searching through the logs.

> Next time you get a freeze, could you
> 1/ strace the process to see what it is blocking on?

# ps -ef | grep sqlgrey
sqlgrey   6538     1  0 20:52 ?        00:00:00 /usr/bin/perl -w
/var/lib/sqlgrey/sqlgrey -d
postgres  9246  5306  0 21:52 ?        00:00:00 postgres: sqlgrey system
127.0.0.1(57579) idle



sqlgrey  10783  6538  0 22:37 ?        00:00:00 [sqlgrey] <defunct>

1 parent process, one (defunct) child process (eh?  how can that be with
clean_method = sync ?).  One connection to the db.

Ok, the strace:

# strace -p 6538
Process 6538 attached - interrupt to quit
poll(

Doesn't say what fd it is polling on. :(

> 2/ At the same time I'm wondering if DBI is leaking connections, could
> you check the number of open connections on PostgreSQL when a freeze
> occur? You can either do a 'ps aux' on the database server to check how
> many connections there are on the sqlgrey database or connect as the
> 'postgres' user on whatever table and execute (I'm not sure if every
> config supports this):
> SELECT * from pg_stat_activity WHERE datname = 'sqlgrey';

Just one connection (see above).

> 
> Lionel.

-- 
 -Rupa