Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Various patches for nextstep by GregorHoffleit

  1. waitpid in pg_basebackup

    Fujii Masao <masao.fujii@gmail.com> — 2012-07-04T16:58:49Z

    Hi,
    
    waitpid() is used with "#ifdef HAVE_WAITPID" in reaper(), but NOT in
    BaseBackup().
    Why not? We can ensure that all platforms which PostgreSQL supports
    have waitpid()?
    If so, can we get rid of "#ifdef HAVE_WAITPID" in reaper()?
    
    Regards,
    
    -- 
    Fujii Masao
    
    
  2. Re: waitpid in pg_basebackup

    Tom Lane <tgl@sss.pgh.pa.us> — 2012-07-04T17:54:47Z

    Fujii Masao <masao.fujii@gmail.com> writes:
    > waitpid() is used with "#ifdef HAVE_WAITPID" in reaper(), but NOT in
    > BaseBackup().
    > Why not? We can ensure that all platforms which PostgreSQL supports
    > have waitpid()?
    > If so, can we get rid of "#ifdef HAVE_WAITPID" in reaper()?
    
    The Single Unix Spec V2 (1997) specifies both waitpid() and wait3(),
    but says the latter is "legacy" and new applications should use only
    waitpid(); furthermore it documents that platforms need not support
    wait3() (they can just return ENOSYS instead of making it work).
    
    I notice that pgbench also uses waitpid() unconditionally in its
    "#ifndef ENABLE_THREAD_SAFETY" section.  That's been there for
    quite some time, making it even less likely that there are still
    any platforms where waitpid() isn't available.
    
    I agree, let's drop the support for waitpid() not being present.
    It looks to me like we could remove the macro maze in reaper()
    completely, if we fixed win32_waitpid() to not have an API randomly
    different from the real waitpid().  That would be a noticeable
    readability gain there.
    
    			regards, tom lane
    
    
  3. Re: waitpid in pg_basebackup

    Tom Lane <tgl@sss.pgh.pa.us> — 2012-07-05T17:01:25Z

    I wrote:
    > I agree, let's drop the support for waitpid() not being present.
    
    BTW, some digging in the commit logs shows that postmaster.c's
    existing support for using wait3 in place of waitpid was added in
    commit a5494a2d92a2752c610b8b668a7d33478e90c160, "Various patches for
    nextstep by GregorHoffleit".  NextStep is presumably quite dead by
    now, and anyway we officially pulled support for it as of 9.2.
    
    I will go ahead and remove that code.
    
    			regards, tom lane
    
    
  4. Re: waitpid in pg_basebackup

    Fujii Masao <masao.fujii@gmail.com> — 2012-07-05T17:43:33Z

    On Fri, Jul 6, 2012 at 2:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > I wrote:
    >> I agree, let's drop the support for waitpid() not being present.
    >
    > BTW, some digging in the commit logs shows that postmaster.c's
    > existing support for using wait3 in place of waitpid was added in
    > commit a5494a2d92a2752c610b8b668a7d33478e90c160, "Various patches for
    > nextstep by GregorHoffleit".  NextStep is presumably quite dead by
    > now, and anyway we officially pulled support for it as of 9.2.
    >
    > I will go ahead and remove that code.
    
    Thanks!
    
    BTW, I was just implementing the patch ;) Patch attached.
    Note that I've not tested the patch on Windows environment
    because I don't have that....
    
    Regards,
    
    -- 
    Fujii Masao
    
  5. Re: waitpid in pg_basebackup

    Tom Lane <tgl@sss.pgh.pa.us> — 2012-07-05T18:12:23Z

    Fujii Masao <masao.fujii@gmail.com> writes:
    > On Fri, Jul 6, 2012 at 2:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> I will go ahead and remove that code.
    
    > Thanks!
    
    > BTW, I was just implementing the patch ;) Patch attached.
    
    Oh, I'd already done it when I got your message :-(.  Looks like we
    arrived at the same answers, though, except for slightly different
    choices for how to do the Windows bit.
    
    > Note that I've not tested the patch on Windows environment
    > because I don't have that....
    
    Me either; I'll check the buildfarm results later.
    
    			regards, tom lane