Re: Listen / Notify - what to do when the queue is full

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Listen / Notify - what to do when the queue is full
Дата
Msg-id 12254.1266264016@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Listen / Notify - what to do when the queue is full  (Joachim Wieland <joe@mcknight.de>)
Ответы Re: Listen / Notify - what to do when the queue is full  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Joachim Wieland <joe@mcknight.de> writes:
> We could probably fake this on the Hot Standby in the following way:

> We introduce a commit record for every notifying transaction and write
> it into the queue itself. So right before writing anything else, we
> write an entry which informs readers that the following records are
> not yet committed. Then we write the actual notifications and commit.
> In post-commit we return back to the commit record and flip its
> status.

This doesn't seem likely to work --- it essentially makes commit non
atomic.  There has to be one and only one authoritative reference as
to whether transaction X committed.

I think that having HS slave sessions issue notifies is a fairly silly
idea anyway.  They can't write the database, so exactly what condition
are they going to be notifying others about?

What *would* be useful is for HS slaves to be able to listen for notify
messages issued by writing sessions on the master.  This patch gets rid
of the need for LISTEN to change on-disk state, so in principle we can
do it.  The only bit we seem to lack is WAL transmission of the messages
(plus of course synchronization in case a slave session is too slow
about picking up messages).  Definitely a 9.1 project at this point
though.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Explain buffers display units.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Avoiding bad prepared-statement plans.