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
