Re: waitpid in pg_basebackup
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-07-04T17:54:47Z
Lists: pgsql-hackers
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Various patches for nextstep by GregorHoffleit
- a5494a2d92a2 7.1.1 cited