Re: base backup client as auxiliary backend process
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Sergei Kornilov <sk@zsrv.org>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-02-03T09:37:25Z
Lists: 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
Commits
-
Factor out InitControlFile() from BootStrapXLOG()
- 79c2385915dd 13.0 landed
-
Reformat code comment
- 9745f93afc56 13.0 landed
-
pg_resetwal: Rename function to avoid potential conflict
- 5f1b8260af96 13.0 landed
-
Expose PQbackendPID() through walreceiver API
- ee4ac46c8eb2 13.0 landed
-
walreceiver uses a temporary replication slot by default
- 329730827848 13.0 landed
-
Make lsn argument of walrcv_create_slot() optional
- c67a55da4ea0 13.0 landed
-
More precise errors from initial pg_control check
- b85e43feb3e8 13.0 landed