On Wed, Jan 11, 2012 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The obvious first use case for this is for cache invalidation.
Yeah, upthread Simon pointed out that propagating notifies would be
useful for flushing caches in applications that watch the database in a
read-only fashion.
Many people clearly do think this is useful.
It also comes under the heading of avoiding surprising behavior. That
is, users instinctively expect to be able to LISTEN on standbys, and are
surprised when they can't.
I personally don't think it will be that complex. I'm willing to
review and
On Wed, Jan 11, 2012 at 4:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW ... it occurs to me to ask whether we really have a solid use-case
for having listeners attached to slave servers. I have personally never
seen an application for LISTEN/NOTIFY in which the listeners were
entirely
Tom,
BTW ... it occurs to me to ask whether we really have a solid use-case
for having listeners attached to slave servers. I have personally never
seen an application for LISTEN/NOTIFY in which the listeners were
entirely read-only. Even if there are one or two cases out there, it's
not
Josh Berkus j...@agliodbs.com writes:
BTW ... it occurs to me to ask whether we really have a solid use-case
for having listeners attached to slave servers. I have personally never
seen an application for LISTEN/NOTIFY in which the listeners were
entirely read-only. Even if there are one or
Yeah, upthread Simon pointed out that propagating notifies would be
useful for flushing caches in applications that watch the database in a
read-only fashion. I grant that such a use-case is technically possible
within the limitations of a slave server; I'm just dubious that it's a
On 11 January 2012 23:51, Josh Berkus j...@agliodbs.com wrote:
Yeah, upthread Simon pointed out that propagating notifies would be
useful for flushing caches in applications that watch the database in a
read-only fashion. I grant that such a use-case is technically possible
within the
On Tue, Jan 10, 2012 at 5:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
[ send NOTIFYs to slaves by means of: ]
Good idea.
I wonder whether it'd be practical to not involve WAL per se in this
at all, but to transmit NOTIFY messages by having walsender
On Tue, Jan 10, 2012 at 12:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So this design is non-optimal both for existing uses and for the
proposed new uses, which means nobody will like it. You could
ameliorate #1 by adding a GUC that determines whether NOTIFY actually
writes WAL, but that's
On Tue, Jan 10, 2012 at 12:56 PM, Joachim Wieland j...@mcknight.de wrote:
I chose to do it this way because it seemed like the most natural way
to do it (which of course doesn't mean it's the best) :-).
If its any consolation its exactly how I would have done it also up
until about 2 months
Simon Riggs si...@2ndquadrant.com writes:
On Tue, Jan 10, 2012 at 5:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be a bit tricky to get walreceivers to inject
the data into the slave-side ring buffer at the right time, ie, not
until after the commit a given message describes has been
On Tue, Jan 10, 2012 at 4:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, Jan 10, 2012 at 5:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be a bit tricky to get walreceivers to inject
the data into the slave-side ring buffer at the right time,
On Tue, Jan 10, 2012 at 11:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
[ Tom sketches a design ]
Seems a bit overcomplicated. I was just thinking of having walreceiver
note the WAL endpoint at the instant of receipt of a notify message,
and not release
Joachim Wieland j...@mcknight.de writes:
On Tue, Jan 10, 2012 at 11:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Suggest we add something to initial handshake from standby to say
please send me notify traffic,
+1 on that.
From what you said I imagined
BTW ... it occurs to me to ask whether we really have a solid use-case
for having listeners attached to slave servers. I have personally never
seen an application for LISTEN/NOTIFY in which the listeners were
entirely read-only. Even if there are one or two cases out there, it's
not clear to me
Joachim Wieland j...@mcknight.de writes:
[ send NOTIFYs to slaves by means of: ]
In the patch I added a new WAL message type, XLOG_NOTIFY that writes
out WAL records when the notifications are written into the pages of
the SLRU ring buffer. Whenever an SLRU page is found to be full, a new
WAL
16 matches
Mail list logo
