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

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>

To: Simon Riggs <simon@2ndQuadrant.com>

Cc: Joachim Wieland <joe@mcknight.de>, Alvaro Herrera <alvherre@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, Greg Smith <greg@2ndquadrant.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, "Florian G. Pflug" <fgp@phlo.org>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org, Arnaud Betremieux <arnaud.betremieux@keyconsulting.fr>

Date: 2010-02-15T21:36:55Z

Lists: pgsql-hackers

On Sun, 2010-02-14 at 22:44 +0000, Simon Riggs wrote:
> * 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;

My first reaction is that it should not be optional. If we allow a slave
system to LISTEN on a condition, what's the point if it doesn't receive
the notifications from the master?

Cache invalidation seems to be the driving use case for LISTEN/NOTIFY.
Only the master can invalidate the cache (as Tom points out downthread);
and users on the slave system want to know about that invalidation if
they are explicitly listening for it.

Regards,
	Jeff Davis