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

From: "Jelte Fennema-Nio" <postgres(at)jeltef(dot)nl>
To: "Andres Freund" <andres(at)anarazel(dot)de>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Heikki Linnakangas" <hlinnaka(at)iki(dot)fi>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Tomas Vondra" <tomas(at)vondra(dot)me>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Peter Eisentraut" <peter(at)eisentraut(dot)org>
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Date: 2025-12-07 15:55:17
Message-ID: DES3UPNP0UXY.35SEHGJ8F8OEQ@jeltef.nl
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue Feb 11, 2025 at 8:42 PM CET, Andres Freund wrote:
> Not sure that's quite the right thing to do for postmaster. What I'd start
> with is to increase the soft limit to
> "already used files" + max_files_per_process.

I needed to rebase this patch, and that made me finally take the time to
do the restoration of the file limit for subprocesses properly: In
previous versions of this patch it restored the limit before the call to
system() and it didn't restore it at all for popen. This latest version
the patch adds custom pg_system() and pg_popen() functions that restore
the limits in the child process right after the fork, but before the
exec.

There are two reasons to do this:
1. Any executables that still use select(2) will get clear "out of file
descriptors" errors instead of failing in mysterious ways.
2. Future looking when we'll have multi-threading (which this change is
needed for) it would be problematic to restore the original limit
temporarily in the postgres process tree. Some other thread might
want to open a file while the limit is too low. By only calling
setrlimit with the lower value in the child process there's not a
single moment where the original Postgres process has a too low limit.

Attachment Content-Type Size
v9-0001-Bump-postmaster-soft-open-file-limit-RLIMIT_NOFIL.patch text/x-patch 22.0 KB
v9-0002-Reflect-the-value-of-max_safe_fds-in-max_files_pe.patch text/x-patch 1.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2025-12-07 16:03:00 Re: Adding REPACK [concurrently]
Previous Message jian he 2025-12-07 15:50:37 Re: UPDATE run check constraints for affected columns only