Re: pg_basebackup behavior on non-existent slot

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup behavior on non-existent slot
Date: 2017-09-12 17:35:58
Message-ID: CAMkU=1xuF8mT30P+3CCx9iMpGpQgxSQpCDx2vgb-YFcHkhxNEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 6, 2017 at 2:50 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> Magnus Hagander wrote:
> > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
> > > Should the parent process of pg_basebackup be made to respond to
> SIGCHLD?
> > > Or call waitpid(bgchild, &status, WNOHANG) in some strategic loop?
> >
> > I think it's ok to just call waitpid() -- we don't need to react super
> > quickly, but we should react.
>
> Hmm, not sure about that ... in the normal case (slotname is correct)
> you'd be doing thousands of useless waitpid() system calls during the
> whole operation, no? I think it'd be better to have a SIGCHLD handler
> that sets a flag (just once), which can be quickly checked without
> accessing kernel space.
>

If we don't want polling by waitpid, then my next thought would be to move
the data copy into another process, then have the main process do nothing
but wait for the first child to exit. If the first to exit is the WAL
receiver, then we must have an error and the data receiver can be killed.
I don't know how to translate that to Windows, however.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-12 17:37:49 Re: domain type smashing is expensive
Previous Message Emre Hasegeli 2017-09-12 17:30:44 Re: [PATCH] Improve geometric types