From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Obsolete coding in fork_process.c
Date: Thu, 1 May 2014 21:24:56 -0400
Message-ID: <20140502012456.GB1191730@tornado.leadboat.com> (raw)
In-Reply-To: <8749.1398991486@sss.pgh.pa.us>
References: <30040.1398960808@sss.pgh.pa.us>
<20140501183231.GA1190179@tornado.leadboat.com>
<4013.1398971788@sss.pgh.pa.us>
<28165.1398981548@sss.pgh.pa.us>
<20140502000053.GA1191730@tornado.leadboat.com>
<8749.1398991486@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Thu, May 01, 2014 at 08:44:46PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Thu, May 01, 2014 at 05:59:08PM -0400, Tom Lane wrote:
> >> However ... after looking around I notice that fflush(NULL) is already
> >> being used in parallel pg_dump and pg_upgrade; and at least in the latter
> >> case I'm afraid to change that because it looks like there are probably
> >> other stdio output files open in the process.
>
> > Do those programs, operating in those modes, read from stdin or some other
> > long-lived, pipe-backed FILE*?
>
> Probably not.
Then the use of fflush(NULL) in those programs tells us nothing about the
status of the aforementioned HP-UX bug.
> However, if that's your criterion, I'd say that I'd much
> rather assume that the postmaster doesn't have a pipe connected to stdin
> than that it has no stdio outputs besides stdout/stderr.
Either way, the beneficiary is theoretical; who can tell which one deserves
priority? Let's do what we usually do in the absence of a clear improvement:
keep the longstanding behavior.
> >> BTW, while working on this I noticed that there are a boatload of places
> >> where we use system() or popen() without a prior fflush. I suspect most
> >> of them are safe, or we'd have heard more complaints --- but shouldn't
> >> we clamp down on that?
>
> > You need the fflush() when forking and then using stdio in the child before
> > any exec(). Have you caught wind of any system() or popen() implementation
> > having that property?
>
> You're only considering one aspect of the problem. Yeah, you might not
> get duplicated output unless system() prints something before exec(),
> but we would also like to have causality: that is, whatever we sent to
> stdout before calling system() should appear there before anything the
> child process sends to stdout.
Good point. I suppose a couple of fflush() calls have negligible cost next to
a system() or popen(). Introduce pg_popen()/pg_system(), and adopt a rule
that they are [almost] our only callers of raw popen()/system()?
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, tgl@sss.pgh.pa.us
Subject: Re: Obsolete coding in fork_process.c
In-Reply-To: <20140502012456.GB1191730@tornado.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox