Horton

Re: base backup client as auxiliary backend process

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Sergei Kornilov <sk@zsrv.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-11-22T12:56:03Z
Lists: pgsql-hackers 
On Fri, Nov 22, 2019 at 11:21:53AM +0100, Peter Eisentraut wrote:
> 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 have not looked at the patch, but controlling the generation of the
slot from the client feels much more natural to me.  This reuses the
existing interface, which is consistent, and we avoid a new class of
bugs if there is any need to deal with the cleanup of the slot on the
WAL sender side it itself created.
--
Michael

Commits

  1. Factor out InitControlFile() from BootStrapXLOG()

  2. Reformat code comment

  3. pg_resetwal: Rename function to avoid potential conflict

  4. Expose PQbackendPID() through walreceiver API

  5. walreceiver uses a temporary replication slot by default

  6. Make lsn argument of walrcv_create_slot() optional

  7. More precise errors from initial pg_control check