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

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