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

On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
> Joachim Wieland <joe(at)mcknight(dot)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 thought a bit more about this and don't really understand why we need
an xid at all. When we discussed this before the role of a NOTIFY was to
remind us to refresh a cache, not as a way of delivering a transactional
payload. If the cache refresh use case is still the objective why does
it matter whether we commit or not when we issue a NOTIFY? Surely, the
rare case where we actually abort right at the end of the transaction
will just cause an unnecessary cache refresh.

> 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?

Agreed

> 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.

OK

--
Simon Riggs www.2ndQuadrant.com