Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup

On Fri Apr 4, 2025 at 7:34 PM CEST, Heikki Linnakangas wrote:
> Let's move that 'in_restore_command' business to the caller. It's weird 
> modularity for the function to implicitly behave differently for some 
> callers. 

I definitely agree with the sentiment, and it was what I originally
planned to do. But then I went for this approach anyway because commit
8fb13dd6ab5b explicitely moved all code except for the actual call to
system() out of the PreRestoreCommand()/PostRestoreCommand() section
(which is also described in the code comment). 

So I didn't move the the in_restore_command stuff to the caller, and
improved the function comment to call out this unfortunate coupling. 

> And 'wait_event_info' should only affect pgstat reporting, not 
> actual behavior.

Given that we need to keep the restore command stuff in this function, I
think the only other option is to add a dedicated argument for the
restore command stuff, like "bool is_restore_command". But that would
require every caller, except for the restore command, to pass an
additional "false" as an argument. To me the additionaly noise that that
adds seems like a worse issue than the non-purity we get by
piggy-backing on the wait_event_info argument.

> I don't feel good about the function name. How about pg_system() or 
> something? 

Done 

> postmaster/startup.c also seems like a weird place for it; 
> not sure where it belongs but probably not there. Maybe next to 
> OpenPipeStream() in fd.c, or move both to a new file.

Moved it to fd.c

> Looks a bit funny that both functions are called Restore<something>(). 
> Not sure what to suggest instead though. Maybe RaiseOpenFileLimit() and 
> LowerOpenFileLimit().

Changed them to UseOriginalOpenFileLimit() and
UseOriginalOpenFileLimit()

> What would it take to re-implement popen() with fork+exec? Genuine 
> question; I have a feeling it might be complicated to do correctly on 
> all platforms, but I don't know.

I initially attempted to re-implement it, but after looking at the
fairly complex FreeBSD implementation of popen[1] that suddenly seemed
more trouble than it's worth.

[1]: https://github.com/freebsd/freebsd-src/blob/c98367641991019bac0e8cd55b70682171820534/lib/libc/gen/popen.c#L63-L181