Re: DISCARD ALL failing to acquire locks on pg_listen

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