Horton

Re: base backup client as auxiliary backend process

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread View on postgr.es
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: alvherre@2ndquadrant.com
Cc: peter.eisentraut@2ndquadrant.com, pgsql-hackers@postgresql.org
Date: 2019-09-12T02:47:09Z
Lists: pgsql-hackers 
Hello, thanks for pinging.

At Wed, 11 Sep 2019 19:15:24 -0300, Alvaro Herrera <alvherre@2ndquadrant.com> wrote in <20190911221524.GA16563@alvherre.pgsql>
> On 2019-Aug-30, Peter Eisentraut wrote:
> 
> > Attached is an updated patch for this.  I have changed the initdb option
> > name per suggestion.  The WAL receiver is now started concurrently with
> > the base backup.  There is progress reporting (ps display), fsyncing.
> > Configuration files are not copied anymore.  There is a simple test
> > suite.  Tablespace support is still missing, but it would be
> > straightforward.
> 
> This is an amazing feature.  How come we don't have people cramming to
> review this?

I love it, too. As for me, the reason for hesitating review this
is the patch is said to be experimental. That means 'the details
don't matter, let's discuss it's design/outline.'. So I wanted to
see what the past reviewers comment on the revised shape before I
would stir up the discussion by maybe-pointless comment. (Then
forgotten..)

I'll re-look on this.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

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