Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M249308=pgsql-hackers-arkari@postgresql.org>)
 id 1WgESP-00037w-PF
 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 May 2014 14:28:57 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M249308=pgsql-hackers-arkari@postgresql.org>)
 id 1WgESO-0001gh-Vn
 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 May 2014 14:28:57 +0000
Received: from makus.postgresql.org ([2001:4800:7903:4::125])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <noah@leadboat.com>) id 1WgESN-0001gY-Pf
 for pgsql-hackers@postgresql.org; Fri, 02 May 2014 14:28:55 +0000
Received: from mail-yh0-f53.google.com ([209.85.213.53])
 by makus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <noah@leadboat.com>) id 1WgESK-0006QP-Bs
 for pgsql-hackers@postgresql.org; Fri, 02 May 2014 14:28:54 +0000
Received: by mail-yh0-f53.google.com with SMTP id i57so4173577yha.26
 for <pgsql-hackers@postgresql.org>; Fri, 02 May 2014 07:28:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-type:content-disposition:in-reply-to
 :user-agent;
 bh=qhunpTUTHENDNUb/kg+dkEZMk4o6SFHdpKxsmx24NuQ=;
 b=QGRgdgamU103apkWWr0McY/AyBNG+XP3tTmvmVUKLmO1pbAiSJWqavk45g1sxNnMkj
 O2BjqtwVQZHBLZW6B0zvFFGglAbdhO/6c9wXvvNNqQKqbGYRH8EuZNRW5iE5b7Gjc0y8
 aXhPin/JXCkf5Gvmt7HJjfxUTYrhpOog6NIr75uHv72dAC14zXtw6pcgzHReUGx0WFVx
 eNy3esxphrsOk5i2Q1qVhnOS1+MuR7T9SIr4kriqVO5AQgE7G6zhk/Lywn49kkJDrNN3
 gp6rBiRGbMMWxdIi+DAY6e6bs42TYpA03V7q/LIYUVMDTq9jatD0/Zpcr6OHlfyuM4dd
 d/EQ==
X-Gm-Message-State: 
 ALoCoQmXrYmdS/QZ2mmZC0G4xig7yVPqBc2iMrx7+miBRG7N1oo2/dyO3jcrTLD3asVhspqWPraC
X-Received: by 10.236.91.67 with SMTP id g43mr23298106yhf.146.1399040931260;
 Fri, 02 May 2014 07:28:51 -0700 (PDT)
Received: from tornado.leadboat.com (c-107-4-219-91.hsd1.va.comcast.net.
 [107.4.219.91])
 by mx.google.com with ESMTPSA id k7sm6901119yhj.31.2014.05.02.07.28.50
 for <multiple recipients>
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Fri, 02 May 2014 07:28:50 -0700 (PDT)
Date: Fri, 2 May 2014 10:28:49 -0400
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
Message-ID: <20140502142849.GA1219884@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>
 <11846.1399000071@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <11846.1399000071@sss.pgh.pa.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Pg-Spam-Score: -2.6 (--)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Thu, May 01, 2014 at 11:07:51PM -0400, Tom Lane wrote:
> 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.

Works for me.

-- 
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