Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas@vondra.me>, Jelte Fennema-Nio <postgres@jeltef.nl>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-02-11T21:18:37Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > My suggestion would be to redefine max_files_per_process as the number of > files we try to be able to open in backends. I.e. set_max_safe_fds() would > first count the number of already open fds (since those will largely be > inherited by child processes) and then check if we can open up to > max_files_per_process files in addition. Adjusting the RLIMIT_NOFILE if > necessary. Seems plausible. IIRC we also want 10 or so FDs available as "slop" for code that doesn't go through fd.c. > And when using something like io_uring for AIO, it'd allow to > max_files_per_process in addition to the files requires for the io_uring > instances. Not following? Surely we'd not be configuring that so early in postmaster start? regards, tom lane
Commits
-
Redefine max_files_per_process to control additionally opened files
- adb5f85fa5a0 18.0 landed
-
pgbench: Increase RLIMIT_NOFILE if necessary
- d38bab5edd60 18.0 landed
-
Move extra code out of the Pre/PostRestoreCommand() section.
- 8fb13dd6ab5b 17.0 cited