On Wed, Mar 28, 2012 at 18:12, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> At postmaster startup, we determine the maximum number of open files we can
> handle by trying to open a lot of file descriptors, up to
> max_files_per_process. This is done in set_max_safe_fds(), and the
> determined max_safe_fds value is inherited by child processes at fork().
> However, with EXEC_BACKEND, ie. Windows, it's not inherited, so we always
> run with the initial conservative default of 32.
>
> An obvious fix would be to call set_max_safe_fds() in the child processes,
> although I wonder if that's too expensive. Another option is to pass down
> the value with save_restore_backend_variables().
ISTM that passing down through save_restore_backend_variables() is a
much better choice.
> Thoughts? Although this has apparently always been like this, no-one has
> complained, so I'm thinking that we shouldn't backport this.
We should absolutely *not* backport this. It needs to go through some
proper testing first, it might cause serious effects on some systems.
In particular, it might have yet another round of effects on people
who run with AV enabled...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
