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: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Sergei Kornilov <sk@zsrv.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-02-04T05:28:57Z
Lists: pgsql-hackers 
On Mon, Feb 03, 2020 at 01:37:25AM -0800, Andres Freund wrote:
> On 2020-01-23 15:49:37 -0500, Robert Haas wrote:
>> I assume that's probably discussed on the thread that is linked here,
>> but you shouldn't have to dig through the discussion thread to figure
>> out what the benefits of a change like this are.
> 
> which I fully agree with.
> 
> It's not at all clear to me that the potential downsides of this have
> been fully thought through. And even if they have, they've not been
> documented.

There is this, and please let me add a reference to another complaint
I had about this commit:
https://www.postgresql.org/message-id/20200122055510.GH174860@paquier.xyz
--
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