Re: base backup client as auxiliary backend process - Mailing list pgsql-hackers

From Andres Freund
Subject Re: base backup client as auxiliary backend process
Date
Msg-id 20200203093725.nghei6abij2pwr6o@alap3.anarazel.de
Whole thread Raw
In response to Re: base backup client as auxiliary backend process  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: base backup client as auxiliary backend process  (Michael Paquier <michael@paquier.xyz>)
Re: base backup client as auxiliary backend process  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2020-01-11 10:52:30 +0100, Peter Eisentraut wrote:
> On 2020-01-10 04:32, Masahiko Sawada wrote:
> > I agreed that these patches are useful on its own and 0001 patch and
> 
> committed 0001

over on -committers Robert complained:

On 2020-01-23 15:49:37 -0500, Robert Haas wrote:
> On Tue, Jan 14, 2020 at 8:57 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> > walreceiver uses a temporary replication slot by default
> >
> > If no permanent replication slot is configured using
> > primary_slot_name, the walreceiver now creates and uses a temporary
> > replication slot.  A new setting wal_receiver_create_temp_slot can be
> > used to disable this behavior, for example, if the remote instance is
> > out of replication slots.
> >
> > Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
> > Discussion:
https://www.postgresql.org/message-id/CA%2Bfd4k4dM0iEPLxyVyme2RAFsn8SUgrNtBJOu81YqTY4V%2BnqZA%40mail.gmail.com
> 
> Neither the commit message for this patch nor any of the comments in
> the patch seem to explain why this is a desirable change.
> 
> I assume that's probably discussed on the thread that is linked here,
> but you shouldn't have to dig through the discussion thread to figure
> out what the benefits of a change like this are.

which I fully agree with.


It's not at all clear to me that the potential downsides of this have
been fully thought through. And even if they have, they've not been
documented.

Previously if a standby without a slot was slow receiving WAL,
e.g. because the network bandwidth was insufficient, it'd at some point
just fail because the required WAL is removed. But with this patch that
won't happen - instead the primary will just run out of space. At the
very least this would need to add documentation of this caveat to a few
places.

Perhaps that's worth doing anyway, because it's probably more common for
a standby to just temporarily run behind - but given that this feature
doesn't actually provide any robustness, due to e.g. the possibility of
temporary disconnections or restarts, I'm not sure it's providing all
that much compared to the dangers, for a feature on by default.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Parallel grouping sets
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager