On Mon, Aug 29, 2022 at 9:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
+1, must be OK (pg_dump and pg_upgrade).
Archeology:
commit 79fcde48b229534fd4a5e07834e5e0e84dd38bee
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun Nov 29 01:51:56 1998 +0000
Portability fix for old SunOS releases: fflush(NULL)
https://www.postgresql.org/message-id/199811241847.NAA04690%40tuna.uimage.com
SunOS 4.x was still in some kind of support phase for a few more
years, but I guess they weren't working too hard on conformance and
features, given that SunOS 5 (the big BSD -> System V rewrite) had
come out in '92...
> 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.
Couldn't hurt. (Looking around at our setvbuf() setup to check the
expected stream state in various places... and huh, I hadn't
previously noticed the thing about Windows interpreting line buffering
to mean full buffering. Pfnghghl...)