On Tue, Sep 12, 2017 at 7:35 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Wed, Sep 6, 2017 at 2:50 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > >> Magnus Hagander wrote: >> > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes <jeff.ja...@gmail.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. > > Well, we could do something similar -- run the main process and the streamer in separate threads on windows and have a main thread wait on both. The main thread would have to be in charge of cleanup as well of course. But I think that's likely going to be more complicated than using non blocking libpq APIs. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
