Re: pgsql: walreceiver uses a temporary replication slot by default

At Thu, 13 Feb 2020 16:48:21 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Wed, Feb 12, 2020 at 06:11:06PM +0900, Fujii Masao wrote:
> > On 2020/02/12 7:53, Jehan-Guillaume de Rorthais wrote:
> >> In my humble opinion, I prefer the previous behavior, streaming without
> >> temporary slot, for one reason: primary availability.
> >
> > +1
> >
> >> With temp slot created by default, if one standby lag far behind, it can make
> >> the primary unavailable. We have nothing yet to forbid a slot to fill the
> >> pg_wal partition. How new users creating their first cluster would react in such
> >> situation? I suppose the original discussion was mostly targeting them?
> >> Recovering from this is way more scary than building a standby.
> >>
> >> So the default behavior might not be desirable and maybe
> >> wal_receiver_create_temp_slot might be off by default?
> >>
> >> Note that Kyotaro HORIGUCHI is working on a patch to restricting maximum keep
> >> segments by repslots:
> >>
> >> https://www.postgresql.org/message-id/flat/20190627162256.4f4872b8%40firost#6cba1177f766e7ffa5237789e748da38
> >
> > Yeah, I think it's better to disable this option until something like
> > Horiguchi-san's proposal will have been committed, i.e., until
> > the upper limit on the number (or size) of WAL files that remain
> > for slots become configurable.
>
> Even with that, are we sure this extra feature would be a reason
> sufficient to change the default value of this option to be enabled?

I think the feature (slot limit) is not going to be an reason to
enable it (tmp slot). In the first place I think we cannot determine
the default value generally workable..

> I am not sure about that either. My opinion is that this option is
> useful to have and that it is not really a problem if you have slot
> monitoring on the primary (or a standby for cascading). And I'd like
> to believe that it is a common practice lately for base backups,
> archivers based on pg_receivewal or even logical decoding, but it
> could be surprising for some users who do not do that yet. So
> Jehan-Guillaume's arguments sound also sensible to me (he also
> maintains an automatic failover solution called PAF).
>
> From what I can see nobody really likes the current state of things
> for this option, and that does not come down only to its default
> value. The default GUC value and the way the parameter is loaded by
> the WAL sender are problematic, still easy enough to fix. How do we
> move on from here? I could post a patch based on what Sergei Kornilov
> has sent around [1], but that's Peter's feature. Any opinions?
>
> [1]: https://www.postgresql.org/message-id/20200122055510.GH174860@paquier.xyz

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center