Re: Notify enhancement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Notify enhancement
Date
Msg-id 21766.1166218624@sss.pgh.pa.us
Whole thread Raw
In response to Re: Notify enhancement  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Notify enhancement
Re: Notify enhancement
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Andrew Dunstan wrote:
>> I don't understand how we decide that everybody who needs a given 
>> event+message has got it, if we don't know who (if anyone) is listening? 
>> How do we decide that we no longer need the info in the shmem buffer? 

> Keep a pointer in shared memory for each listener backend, saying how
> far it has scanned the ring?  There would be a single writing pointer,
> so it's trivial to see when the ring is "full".

Right.  Read the code in src/backend/storage/ipc/sinvaladt.c, especially
SIInsertDataEntry, SIGetDataEntry, SIDelExpiredDataEntries.

>> Are we keeping use of SIGUSR2 in this scheme?

> What for?  Just protect the write pointer with a lwlock and have
> listeners check whether somebody has written something.

You do want something comparable to SIGUSR2 to prod active backends to
consume messages, in case they are busy doing a query and hence not
checking the ring.  I'm envisioning something like having the SIGUSR2
signal handler set a flag that's checked by CHECK_FOR_INTERRUPTS(),
and if set then ProcessInterrupts will go off and absorb messages.
Onlookers can tell who's falling behind by noting where their read
pointers are, and can issue SIGUSR2 to the laggards --- in particular,
any backend that finds itself unable to insert a NOTIFY into the ring
for lack of space can SIGUSR2 the laggards and then sleep a little.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Notify enhancement
Next
From: Andrew Dunstan
Date:
Subject: Re: Notify enhancement