"SZŰCS Gábor" <surrano@mailbox.hu> writes:
> A final question: as far as you can remember, may this be an issue already
> fixed in later versions?
I should have looked in the code before, because indeed we have a recent
bug fix addressing exactly this issue. Here's the commit message:
2003-09-15 19:33 tgl
* src/: backend/access/heap/heapam.c, backend/commands/async.c,backend/executor/execMain.c, include/access/heapam.h:
FixLISTEN/NOTIFYrace condition reported by Gavin Sherry. While areally general fix might be difficult, I believe the
onlycasewhere AtCommit_Notify could see an uncommitted tuple is where theother guy has just unlistened and not yet
committed. The bestsolution seems to be to just skip updating that tuple, on theassumption that the other guy does not
wantto hear about thenotification anyway. This is not perfect --- if the other guyrolls back his unlisten instead of
committing,then he reallyshould have gotten this notify. But to do that, we'd have to waitto see if he commits or not,
ormake UNLISTEN hold exclusive lockon pg_listener until commit. Either of these answers isdeadlock-prone, not to
mentionhorrible for interactiveperformance. Do it this way for now. (What happened to thatproject to do LISTEN/NOTIFY
inmemory with no table, anyway?)
This is in 7.4, but not 7.3.*.
You can duplicate the failure like so (in 7.3):
session one:listen foo;begin;unlisten foo;
session two:notify foo;-- hangs
session one:end;
-- session two now says
WARNING: AbortTransaction and not in in-progress state
ERROR: simple_heap_update: tuple concurrently updated
regards, tom lane
