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>, "Peter Eisentraut" <peter(at)eisentraut(dot)org>
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Date: 2026-07-07 08:02:44
Message-ID: DJS6KELUH3T0.2DGCBB9I190X@jeltef.nl
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 7 Dec 2025 at 16:55, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> 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

Rebased yet again

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ewan Young 2026-07-07 08:13:30 Reject ill-formed range bounds histograms in pg_restore_attribute_stats()
Previous Message Jelte Fennema-Nio 2026-07-07 07:54:09 Re: Don't use the deprecated and insecure PQcancel in our frontend tools anymore