Re: Proposed patch for LISTEN/NOTIFY race condition

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, Laurent Birtz <laurent(dot)birtz(at)kryptiva(dot)com>
Subject: Re: Proposed patch for LISTEN/NOTIFY race condition
Date: 2008-03-12 19:12:54
Message-ID: 28627.1205349174@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2008-03-13 00:13:20 Re: CSStorm occurred again by postgreSQL8.2
Previous Message Pavan Deolasee 2008-03-12 17:48:50 Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit