Re: LISTEN and "tuple concurrently updated"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: LISTEN and "tuple concurrently updated"
Date: 2003-09-15 23:46:29
Message-ID: 11637.1063669589@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2003-09-16 00:26:32 Re: LISTEN and "tuple concurrently updated"
Previous Message Tom Lane 2003-09-15 22:30:23 Re: some strange messages