Jeff Davis <pgsql@j-davis.com> writes:
> How does the existing notification mechanism solve this problem? Is it
> really a problem? Why would Backend2 expect to receive the notification?
The intended way to use LISTEN/NOTIFY for status tracking is
1. LISTEN foo; (and commit the listen)2. examine current database state3. assume that we'll get a NOTIFY for any change
thatcommits subsequently to what we saw in step 2
In the current implementation, a transaction that is in process of
commit during step 1 might possibly not see your pg_listener record
as committed, and so it might not send you a NOTIFY for whatever it did.
If it still hasn't committed when you perform step 2, then you'd fail to
see its changes as part of your initial state, *and* you'd not get a
NOTIFY when the changes did become visible. The way we prevent this
race condition is that a listener takes exclusive lock on pg_listener
before entering its record, and doesn't release the lock until after
committing. Notifiers likewise take exclusive lock. This serializes
things so that either the modifying transaction commits before the
listener completes step 1 (and hence the listener will see its updates
in step 2), or the listener is guaranteed to have a committed record
in pg_listener when the modifying process determines whom to notify.
I guess Joachim is trying to provide a similar guarantee for the new
implementation, but I'm not clear on why it would require locking.
The new implementation is broadcast and ISTM it shouldn't require the
modifying transaction to know which processes are listening.
I haven't read the patch but I agree that the description you give is
pretty scary from a performance standpoint. More locks around
transaction commit doesn't seem like a good idea. If they're only taken
when an actual LISTEN or NOTIFY has happened in the current transaction,
that'd be okay (certainly no worse than what happens now) but the naming
suggested that this'd happen unconditionally.
regards, tom lane