Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Date
Msg-id 3208430.1739304022@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: injection points for hash aggregation
Next
From: Tom Lane
Date:
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup