Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M249289=pgsql-hackers-arkari@postgresql.org>)
 id 1Wg2Dp-000787-Cg
 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 May 2014 01:25:05 +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+M249289=pgsql-hackers-arkari@postgresql.org>)
 id 1Wg2Do-0005DW-QJ
 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 May 2014 01:25:04 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <noah@leadboat.com>) id 1Wg2Do-0005DO-1Q
 for pgsql-hackers@postgresql.org; Fri, 02 May 2014 01:25:04 +0000
Received: from mail-yh0-f42.google.com ([209.85.213.42])
 by magus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <noah@leadboat.com>) id 1Wg2Dk-0002oB-BJ
 for pgsql-hackers@postgresql.org; Fri, 02 May 2014 01:25:03 +0000
Received: by mail-yh0-f42.google.com with SMTP id f73so3614368yha.15
 for <pgsql-hackers@postgresql.org>; Thu, 01 May 2014 18:24:58 -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=ivHfqmu2h1wCmcmvegJ+ItN4rX1fgBXk6iQr1PJNY/Y=;
 b=gF//PGXO0fuFmiHCk1qTPoMyJ9BOAAtPfUx6qC/n8TzCLxrUcZNsL9TodpvAkPlcQf
 TgP+1a2D0exmPsLrFMkVTDq6zJtLkcvgMTWrD68oEBrxiNu/HsavwMpSHn7cVTc7ij4M
 yFznO8qLqkCV148Y+ky04YGSVupGCaTuZoogK/LEk6xwdoEiftFFH50wN3JfqYXC6D5z
 AJrfVFo3ROeR5cDWwpCMZcoCmKGF831kfzdD8/d0xB5bgjG2QXzN8ffES0uMdXc+8Uzn
 Ik7LbiY+o47B7iVSCMfn58SFU/lbHFzhR59Od2WelraKdMdba9h470QKKhbKc2CM9gxv
 SP8g==
X-Gm-Message-State: 
 ALoCoQmLxPBoE3PonOTbCIxuWN07Zl66HN5Gri8nxIgZGLA4SRhSNvjAvRmv1xUP0pl6HyuGw48+
X-Received: by 10.236.231.6 with SMTP id k6mr19062324yhq.156.1398993898558;
 Thu, 01 May 2014 18:24:58 -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 j76sm51912091yhi.33.2014.05.01.18.24.57
 for <multiple recipients>
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Thu, 01 May 2014 18:24:57 -0700 (PDT)
Date: Thu, 1 May 2014 21:24:56 -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: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8749.1398991486@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 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