Matteo Beccati <p...@beccati.com> writes:
> 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
