On Fri, 22 Nov 2019 at 19:22, Peter Eisentraut <peter.eisentr...@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
