Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Ibrar Ahmed
Subject Re: Cleaning up historical portability baggage
Date
Msg-id CALtqXTcb7baV39KODc+2xN4y_8794yDkrbcwi2y1SkGxUs7OEA@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Cleaning up historical portability baggage
List pgsql-hackers


On Mon, Aug 29, 2022 at 3:13 AM Thomas Munro <thomas.munro@gmail.com> wrote:
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...)


The patch does not apply successfully; please rebase the patch.
patching file src/backend/postmaster/fork_process.c
Hunk #1 FAILED at 37.
1 out of 1 hunk FAILED -- saving rejects to file src/backend/postmaster/fork_process.c.rej
patching file src/backend/storage/file/fd.c
Hunk #1 FAILED at 2503.
1 out of 1 hunk FAILED -- saving rejects to file src/backend/storage/file/fd.c.rej
patching file src/backend/utils/error/elog.c
Hunk #1 FAILED at 643.
Hunk #2 FAILED at 670.


--
Ibrar Ahmed

pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Next
From: Nikita Malakhov
Date:
Subject: Re: Counterintuitive behavior when toast_tuple_target < TOAST_TUPLE_THRESHOLD