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
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 |