Re: Listen / Notify - what to do when the queue is full - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Listen / Notify - what to do when the queue is full
Date
Msg-id 12254.1266264016@sss.pgh.pa.us
Whole thread Raw
In response to Re: Listen / Notify - what to do when the queue is full  (Joachim Wieland <joe@mcknight.de>)
Responses Re: Listen / Notify - what to do when the queue is full
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Explain buffers display units.
Next
From: Robert Haas
Date:
Subject: Re: Avoiding bad prepared-statement plans.