Jeff Davis <pg...@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 state 3. assume that we'll get a NOTIFY for any change that commits 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers