Gavin Sherry <[EMAIL PROTECTED]> writes:
> A user on IRC came across the following "tuple concurrently updated" error
> when using LISTEN/NOTIFY intensively.
I've applied a fix for this to CVS tip.
Thinking about the implications of rolling back UNLISTEN, it occurs to
me that there is another possible solution, which is to queue up LISTEN
and UNLISTEN commands locally in the backend and not apply them to
pg_listener until commit. Doing it this way, it'd be okay to hold the
pg_listener lock until commit, which would eliminate the problem of
uncommitted unlistens being visible to notifiers. However it would
require adding a fair amount more code to async.c.
I think that whenever we get around to rewriting LISTEN/NOTIFY to use
shared memory messages instead of a table, it will be necessary to apply
listen/unlisten commands that way (hold them until commit) to preserve
transactional semantics. But for now, I'm not going to do the extra
work.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
