Обсуждение: pgsql-server/src backend/access/heap/heapam.c ...

CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    tgl@svr1.postgresql.org    03/09/15 20:33:43

Modified files:
    src/backend/access/heap: heapam.c
    src/backend/commands: async.c
    src/backend/executor: execMain.c
    src/include/access: heapam.h

Log message:
    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?)

> CVSROOT:    /cvsroot
> Module name:    pgsql-server
> Changes by:    tgl@svr1.postgresql.org    03/09/15 20:33:43
>
> Modified files:
>     src/backend/access/heap: heapam.c
>     src/backend/commands: async.c
>     src/backend/executor: execMain.c
>     src/include/access: heapam.h
>
> Log message:
[snip]
>     (What happened to that project to do LISTEN/NOTIFY in memory
>     with no table, anyway?)

You mean TelegraphCQ?

http://telegraph.cs.berkeley.edu/telegraphcq/v0.2/

Seems to be alive and kicking, though I bet things slowed down because
of summer qtr.  -sc

--
Sean Chittenden

Sean Chittenden <sean@chittenden.org> writes:
> [snip]
>> (What happened to that project to do LISTEN/NOTIFY in memory
>> with no table, anyway?)

> You mean TelegraphCQ?

No, I meant this discussion:
http://archives.postgresql.org/pgsql-hackers/2002-03/msg00968.php
I'm not sure if Telegraph is really doing the same thing.

            regards, tom lane

On Mon, 2003-09-15 at 20:19, Tom Lane wrote:
> Sean Chittenden <sean@chittenden.org> writes:
> > [snip]
> >> (What happened to that project to do LISTEN/NOTIFY in memory
> >> with no table, anyway?)

Thanks for the reminder -- I'd like to implement this, but I can't say
when I'll get the time. In the mean while, anyone else who would like to
do the work is welcome to.

> I'm not sure if Telegraph is really doing the same thing.

As far as I can see, TelegraphCQ (which is distinct from Telegraph) has
nothing to do with a shm-based LISTEN/NOTIFY implementation.

-Neil

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