Re: Cleaning up historical portability baggage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cleaning up historical portability baggage
Date: 2022-08-28 21:40:25
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Here's another bit of baggage handling: fixing up the places that
were afraid to use fflush(NULL). We could doubtless have done
this years ago (indeed, I found several places already using it)
but as long as we're making a push to get rid of obsolete code,
doing it now seems appropriate.

One thing that's not clear to me is what the appropriate rules
should be for popen(). POSIX makes clear that you shouldn't
expect popen() to include an fflush() itself, but we seem quite
haphazard about whether to do one or not before popen(). In
the case of popen(..., "r") we can expect that the child can't
write on our stdout, but stderr could be a problem anyway.

Likewise, there are some places that fflush before system(),
but they are a minority. Again it seems like the main risk
is duplicated or mis-ordered stderr output.

I'm inclined to add fflush(NULL) before any popen() or system()
that hasn't got one already, but did not do that in the attached.


regards, tom lane

Attachment Content-Type Size
use-fflush-NULL-where-appropriate.patch text/x-diff 5.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-08-28 21:52:43 Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Previous Message Nathan Bossart 2022-08-28 21:29:52 Re: add checkpoint stats of snapshot and mapping files of pg_logical dir