Re: base backup client as auxiliary backend process
От | Masahiko Sawada |
---|---|
Тема | Re: base backup client as auxiliary backend process |
Дата | |
Msg-id | CA+fd4k4BcYrYucNfTnK-CQX3+jsG+PRPEhHAUSo-W4P0Lec57A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: base backup client as auxiliary backend process (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: base backup client as auxiliary backend process
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: