Re: Proposed patch for LISTEN/NOTIFY race condition - Mailing list pgsql-patches

From Tom Lane
Subject Re: Proposed patch for LISTEN/NOTIFY race condition
Date
Msg-id 28627.1205349174@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposed patch for LISTEN/NOTIFY race condition  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-patches
Alvaro Herrera <alvherre@commandprompt.com> 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 to make NOTIFY use SnapshotDirty to
> examine pg_listener, thus causing it to see the uncommitted rows.  Would
> that work at all?

I don't think so.  NOTIFY has to update the rows, not only see them,
and you can't update someone else's uncommitted row.  In any case we'd
be venturing into uncharted territory, which isn't something I'd want
to backpatch.  The existing patch is just altering the timing of the
same actions we take already, so it seems a lot safer.  IMHO anyway.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Next
From: Robert Lor
Date:
Subject: Re: DTrace probe patch for OS X Leopard