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

On Mon, 2010-02-15 at 12:59 +0100, Joachim Wieland wrote:
> On Sun, Feb 14, 2010 at 11:44 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > Next set of questions
> >
> > * Will this work during Hot Standby now? The barrier was that it wrote
> > to a table and so we could not allow that. ISTM this new version can and
> > should work with Hot Standby. Can you test that and if so, remove the
> > explicit barrier code and change tests and docs to enable it?
> 
> I have tested it already. The point where it currently fails is the
> following line:
> 
>     qe->xid = GetCurrentTransactionId();
> 
> We record the TransactionId (of the notifying transaction) in the
> notification in order to later check if this transaction has committed
> successfully or not. If you tell me how we can find this out in HS, we
> might be done...
> 
> The reason why we are doing all this is because we fear that we can
> not write the notifications to disk once we have committed to clog...
> So we write them to disk before committing to clog and therefore need
> to record the TransactionId.

That's a shame. So it will never work in Hot Standby mode unless you can
think of a different way.

> > * We also discussed the idea of having a NOTIFY command that would work
> > from Primary to Standby. All this would need is some code to WAL log the
> > NOTIFY if not in Hot Standby and for some recovery code to send the
> > NOTIFY to any listeners on the standby. I would suggest that would be an
> > option on NOTIFY to WAL log the notification:
> > e.g. NOTIFY me 'with_payload' FOR STANDBY ALSO;
> 
> What should happen if you wanted to replay a NOTIFY WAL record in the
> standby but cannot write to the pg_notify/ directory?

Same thing that happens to any action that cannot be replayed. Why
should that be a problem?

-- Simon Riggs           www.2ndQuadrant.com