| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Arnaud Betremieux <arnaud(dot)betremieux(at)keyconsulting(dot)fr> |
| Subject: | Re: Listen / Notify - what to do when the queue is full |
| Date: | 2010-02-15 21:36:55 |
| Message-ID: | 1266269815.29919.6947.camel@jdavis |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hans-Jürgen Schönig | 2010-02-15 21:50:29 | one more index for pg_tablespace? |
| Previous Message | Jeff Davis | 2010-02-15 21:24:37 | Re: LISTEN/NOTIFY versus encoding conversion |