"=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <[EMAIL PROTECTED]> 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: 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 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
