pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Obsolete coding in fork_process.c
Date: Thu, 01 May 2014 23:07:51 -0400
Message-ID: <11846.1399000071@sss.pgh.pa.us> (raw)
In-Reply-To: <20140502012456.GB1191730@tornado.leadboat.com>
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>
	<20140502012456.GB1191730@tornado.leadboat.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Noah Misch <noah@leadboat.com> writes:
> On Thu, May 01, 2014 at 08:44:46PM -0400, Tom Lane wrote:
>> 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()?

Meh.  I'm not usually in favor of adopting nonstandard notation, and
this doesn't seem like a place to start.  In particular, if you don't
want to use fflush(NULL) in these proposed wrappers, then call sites
are still going to have an issue with needing to do manual fflushes;
pg_regress.c's spawn_process is an example:

    /*
     * Must flush I/O buffers before fork.  Ideally we'd use fflush(NULL) here
     * ... does anyone still care about systems where that doesn't work?
     */
    fflush(stdout);
    fflush(stderr);
    if (logfile)
        fflush(logfile);

    pid = fork();

I think that removing the need for fflush(stdout) and fflush(stderr)
in this context would mostly result in people forgetting to fflush
other output files.  I'd rather have the two lines of boilerplate
(and a comment about why we're refusing to depend on fflush(NULL))
than take that risk.

Now, if you were willing to put fflush(NULL) into the wrappers,
I could get on board with that ;-)

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (10+ messages)  latest in thread

Message-ID: <11846.1399000071@sss.pgh.pa.us>
Permalink:  ../11846.1399000071@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/11846.1399000071@sss.pgh.pa.us

 · 

reply

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: tgl@sss.pgh.pa.us, noah@leadboat.com
  Subject: Re: Obsolete coding in fork_process.c
  In-Reply-To: <11846.1399000071@sss.pgh.pa.us>

* 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