Re: Notify enhancement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Notify enhancement
Дата
Msg-id 21766.1166218624@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Notify enhancement  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Notify enhancement  (Andrew Dunstan <andrew@dunslane.net>)
Re: Notify enhancement  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Notify enhancement
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Notify enhancement