> 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
On Wed, Jan 11, 2012 at 11:38 PM, Tom Lane 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. I grant that
On 11 January 2012 23:51, Josh Berkus 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 limitations of
> 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
> suff
Josh Berkus 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 two cases
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
> n
On Wed, Jan 11, 2012 at 4:33 AM, Tom Lane 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 read-only. Even if t
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 t
Joachim Wieland writes:
> On Tue, Jan 10, 2012 at 11:55 AM, Tom Lane wrote:
>> Simon Riggs 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 this walsender listener as a regular
> li
On Tue, Jan 10, 2012 at 11:55 AM, Tom Lane wrote:
> Simon Riggs 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 the notify message to the slave ri
On Tue, Jan 10, 2012 at 4:55 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Tue, Jan 10, 2012 at 5:00 AM, Tom Lane 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
Simon Riggs writes:
> On Tue, Jan 10, 2012 at 5:00 AM, Tom Lane 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 replayed;
>> but I don't immediately
On Tue, Jan 10, 2012 at 12:56 PM, Joachim Wieland 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 ago, and I remem
On Tue, Jan 10, 2012 at 12:00 AM, Tom Lane 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 pretty ugly. In an
On Tue, Jan 10, 2012 at 5:00 AM, Tom Lane wrote:
> Joachim Wieland 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 processes
> follow the notify str
Joachim Wieland 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 record will
16 matches
Mail list logo
