Hi Tom, >> Given I was using 8.3, it seemed quite right to set the reset statement >> to "ABORT; DISCARD ALL". Everything works fine, until a load spike >> happens and pgpool-II reset queries start to lag behind, with DISCARD >> ALL failing to acquire an exclusive locks on the pg_listen system table, >> although the application isn't using any LISTEN/NOTIFY. The reason was >> not obvious to me, but looking at the man page explained a lot: DISCARD >> ALL also performs an "UNLISTEN *". > > Seems like we could/should fix UNLISTEN * to not do anything if it is > known that the current backend never did any LISTENs.
Here's my proposed patch, both for HEAD and 8.3: http://www.beccati.com/misc/pgsql/async_unlisten_skip_HEAD.patch http://www.beccati.com/misc/pgsql/async_unlisten_skip_REL8_3_STABLE.patch I tried to write a regression test, but couldn't find a suitable way to get the regression framework cope with trace_notify printing the backend pid. I even tried to add a @backend_pid@ variable to pg_regress, but soon realised that the pid is not available to psql when variable substitution happens. So, here's the output of some tests I made: http://www.beccati.com/misc/pgsql/async_unlisten_skip.out Note: DISCARD doesn't produce any debug output, because the guc variables are being reset before the Async_UnlistenAll is called. Cheers -- Matteo Beccati OpenX - http://www.openx.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
