From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Andres Freund <andres@anarazel.de>
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
In-reply-to: <3203865.1739301613@sss.pgh.pa.us>
References: <CAGECzQQh6VSy3KG4pN1d=h9J=D1rStFCMR+t7yh_Kwj-g87aLQ@mail.gmail.com> <3203865.1739301613@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 11 Feb 2025 14:20:13 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3208429.1739304022.1@sss.pgh.pa.us>
Date: Tue, 11 Feb 2025 15:00:22 -0500
Message-ID: <3208430.1739304022@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3208430.1739304022%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Maybe a sanity limit on how high we'll try to raise the ulimit
> would help.

Oh, I'd forgotten that we already have one: max_files_per_process.
Since that's only 1000 by default, this patch doesn't actually have
any effect (on Linux anyway) unless the DBA raises
max_files_per_process.  That alleviates my concern quite a bit.

... but not completely.  You didn't read all of Pid Eins' advice:

    If said program you hack on forks off foreign programs, make sure
    to reset the RLIMIT_NOFILE soft limit back to 1024 for them. Just
    because your program might be fine with fds >= 1024 it doesn't
    mean that those foreign programs might. And unfortunately
    RLIMIT_NOFILE is inherited down the process tree unless explicitly
    set.

I think we'd need to pay some attention to that in e.g. COPY FROM
PROGRAM.  I also wonder whether plperl, plpython, etc can be
guaranteed not to run any code that depends on select(2).

			regards, tom lane