Re: pgsql-server/src backend/access/heap/heapam.c ...

Tom Lane wrote:
> 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?)

Added to TODO:

* Allow LISTEN/NOTIFY to store info in memory rather than tables

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073