Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
От | Alvaro Herrera |
---|---|
Тема | Re: pgsql: Add kqueue(2) support to the WaitEventSet API. |
Дата | |
Msg-id | 20200224205509.GA5686@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pgsql: Add kqueue(2) support to the WaitEventSet API. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
|
Список | pgsql-hackers |
On 2020-Feb-24, Tom Lane wrote: > I wrote: > > I thought about platform-specific messages, but it's not clear to me > > whether our translation infrastructure will find messages that are > > inside #ifdefs ... anyone know? > > Oh, but of course it does. So let's do > > errdetail("There are too many open files on the local server."), > #ifndef WIN32 > errhint("Raise the server's max_files_per_process and/or \"ulimit -n\" limits.") > #else > errhint("Raise the server's max_files_per_process setting.") > #endif WFM. > I don't think there's much point in telling Windows users about > _setmaxstdio() here. Yeah, telling users to _setmaxstdio() themselves is useless, because they can't do it; that's something *we* should do. I think the 512 limit is a bit low; why not increase that a little bit? Maybe just to the Linux default of 1024. Then again, that would be akin to setrlimit() on Linux. Maybe we can consider that a separate GUC, in a separate patch, with a platform-specific default value that just corresponds to the OS's default, and the user can set to whatever suits them; then we call either _setmaxstdio() or setrlimit(). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: