pgsql: Fix bogus when-to-deregister-from-listener-array logic. - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Fix bogus when-to-deregister-from-listener-array logic.
Date
Msg-id E1U5gRp-0004QN-5Y@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Fix bogus when-to-deregister-from-listener-array logic.

Since a backend adds itself to the global listener array during
Exec_ListenPreCommit, it's inappropriate for it to remove itself during
Exec_UnlistenCommit or Exec_UnlistenAllCommit --- that leads to failure
when committing a transaction that did UNLISTEN then LISTEN, since we end
up not registered though we should be.  (This leads to missing later
notifications, or to Assert failures in assert-enabled builds.)  Instead
deal with deregistering at the bottom of AtCommit_Notify, when we know the
final state of the listenChannels list.

Also, simplify the representation of registration status by replacing the
transient backendHasExecutedInitialListen flag with an amRegisteredListener
flag.

Per report from Greg Sabino Mullane.  Back-patch to 9.0, where the problem
was introduced during the LISTEN/NOTIFY rewrite.

Branch
------
REL9_1_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/52c889ea4f7696157fde4b74ae62fbe014d06087

Modified Files
--------------
src/backend/commands/async.c |   60 +++++++++++++++--------------------------
1 files changed, 22 insertions(+), 38 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Fix bogus when-to-deregister-from-listener-array logic.
Next
From: Tom Lane
Date:
Subject: pgsql: Fix contrib/pg_trgm's similarity() function for trigram-free str