On Fri, 22 Nov 2019 at 19:22, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2019-11-15 14:52, Sergei Kornilov wrote:
> >> I looked into this. It seems trivial to make walsender create and use a
> >> temporary replication slot by default if no permanent replication slot
> >> is specified. This is basically the logic that pg_basebackup has but
> >> done server-side. See attached patch for a demonstration. Any reason
> >> not to do that?
> > Seems this would break pg_basebackup --no-slot option?
>
> After thinking about this a bit more, doing the temporary slot stuff on
> the walsender side might lead to too many complications in practice.
>
> Here is another patch set that implements the temporary slot use on the
> walreceiver side, essentially mirroring what pg_basebackup already does.
>
> I think this patch set might be useful on its own, even without the base
> backup stuff to follow.
>
I agreed that these patches are useful on its own and 0001 patch and
0002 patch look good to me. For 0003 patch,
+ linkend="guc-primary-slot-name"/>. Otherwise, the WAL receiver may use
+ a temporary replication slot (determined by <xref
+ linkend="guc-wal-receiver-create-temp-slot"/>), but these are not shown
+ here.
I think it's better to show the temporary slot name on
pg_stat_wal_receiver view. Otherwise user would have no idea about
what wal receiver is using the temporary slot.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services