Re: LISTEN and "tuple concurrently updated"
От | Tom Lane |
---|---|
Тема | Re: LISTEN and "tuple concurrently updated" |
Дата | |
Msg-id | 11637.1063669589@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | LISTEN and "tuple concurrently updated" (Gavin Sherry <swm@linuxworld.com.au>) |
Ответы |
Re: LISTEN and "tuple concurrently updated"
|
Список | pgsql-hackers |
Gavin Sherry <swm@linuxworld.com.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
В списке pgsql-hackers по дате отправления: