1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-27 23:21:58 +03:00

Fix LISTEN/NOTIFY race condition reported by Gavin Sherry. While a

really general fix might be difficult, I believe the only case where
AtCommit_Notify could see an uncommitted tuple is where the other guy
has just unlistened and not yet committed.  The best solution seems to
be to just skip updating that tuple, on the assumption that the other
guy does not want to hear about the notification anyway.  This is not
perfect --- if the other guy rolls back his unlisten instead of committing,
then he really should have gotten this notify.  But to do that, we'd have
to wait to see if he commits or not, or make UNLISTEN hold exclusive lock
on pg_listener until commit.  Either of these answers is deadlock-prone,
not to mention horrible for interactive performance.  Do it this way
for now.  (What happened to that project to do LISTEN/NOTIFY in memory
with no table, anyway?)
This commit is contained in:
Tom Lane
2003-09-15 23:33:43 +00:00
parent d73e1b33b5
commit db18703b5a
4 changed files with 92 additions and 19 deletions

View File

@ -26,7 +26,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/executor/execMain.c,v 1.216 2003/08/08 21:41:34 momjian Exp $
* $Header: /cvsroot/pgsql/src/backend/executor/execMain.c,v 1.217 2003/09/15 23:33:43 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -1406,7 +1406,8 @@ ExecDelete(TupleTableSlot *slot,
ldelete:;
result = heap_delete(resultRelationDesc, tupleid,
&ctid,
estate->es_snapshot->curcid);
estate->es_snapshot->curcid,
true /* wait for commit */);
switch (result)
{
case HeapTupleSelfUpdated:
@ -1540,7 +1541,8 @@ lreplace:;
*/
result = heap_update(resultRelationDesc, tupleid, tuple,
&ctid,
estate->es_snapshot->curcid);
estate->es_snapshot->curcid,
true /* wait for commit */);
switch (result)
{
case HeapTupleSelfUpdated: