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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073