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

From: "Jelte Fennema-Nio" <postgres(at)jeltef(dot)nl>
To: "surya poondla" <suryapoondla4(at)gmail(dot)com>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Andres Freund" <andres(at)anarazel(dot)de>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "tomas(at)vondra(dot)me" <tomas(at)vondra(dot)me>, <hlinnaka(at)iki(dot)fi>, "Peter Eisentraut" <peter(at)eisentraut(dot)org>, "Haibo Yan" <tristan(dot)yim(at)gmail(dot)com>
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Date: 2026-11-04 21:09:55
Message-ID: DMMQGHNY6L1B.26UQKGE6LVBCA@jeltef.nl
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 16 Sept 2026 at 01:04, surya poondla <suryapoondla4(at)gmail(dot)com> wrote:
> 1. Report the setrlimit() failure from the parent, drop it, or emit it with a plain write(2), so that the child path contains only syscall-level work.
> 2. Add a comment on fork_for_shell_command() stating the constraint. This is new infrastructure that will have more additions, and the hazard is invisible from the call site.
> 3. In pg_popen()'s child, dup2()'s return value isn't checked. On failure the child would exec with the parent's descriptor still in place, so the
> command's output would go elsewhere and the parent would see immediate EOF with no error.

I've addressed these three. see attached

Attachment Content-Type Size
v12-0001-Bump-postmaster-soft-open-file-limit-RLIMIT_NOFI.patch text/x-patch 22.6 KB
v12-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 Narek Galstyan 2026-11-04 21:30:30 Re: Unlogged bloom indexes break after crash recovery
Previous Message Bharath Rupireddy 2026-11-04 21:09:44 Re: Use WALReadFromBuffers in more places