Re: [PATCHES] Proposed patch for LISTEN/NOTIFY race condition

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The patch disallows LISTEN/NOTIFY in a prepared transaction, and there >> is also a side effect on whether a transaction can see entries in >> pg_listener for its own uncommitted LISTEN commands. > I wonder if it would've been easier

Re: [PATCHES] Proposed patch for LISTEN/NOTIFY race condition

Tom Lane wrote: > The patch disallows LISTEN/NOTIFY in a prepared transaction, and there > is also a side effect on whether a transaction can see entries in > pg_listener for its own uncommitted LISTEN commands. I wonder if it would've been easier to make NOTIFY use SnapshotDirty to examine pg_li

Re: [PATCHES] Proposed patch for LISTEN/NOTIFY race condition

I wrote: > The patch disallows LISTEN/NOTIFY in a prepared transaction, I meant LISTEN/UNLISTEN, of course. See pghackers discussion here: http://archives.postgresql.org/pgsql-hackers/2008-03/msg00290.php regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-p

[PATCHES] Proposed patch for LISTEN/NOTIFY race condition

This patch responds to the problem reported by Laurent Birtz here: http://archives.postgresql.org/pgsql-bugs/2008-03/msg00094.php The difficulty is that LISTEN modifies pg_listener and then releases lock early, so that there is an interval where a concurrent NOTIFY doesn't see the pg_listener entry