Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
От | Alvaro Herrera |
---|---|
Тема | Re: pgsql: Add kqueue(2) support to the WaitEventSet API. |
Дата | |
Msg-id | 20200316203040.GA4019@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pgsql: Add kqueue(2) support to the WaitEventSet API. (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
|
Список | pgsql-committers |
On 2020-Mar-17, Thomas Munro wrote: > Reproduced here. The problem seems to be that macOS's getppid() > returns the debugger's PID, while the debugger is attached. This > doesn't happen on FreeBSD (even though the debugger does internally > become the parent, getppid() is careful to return the "real" parent > PID so that user space doesn't notice this trickery; apparently Apple > made a different choice). Wow ... Yeah, that was a known problem with FreeBSD, see https://postgr.es/m/1292851036-sup-5399@alvh.no-ip.org Evidently FreeBSD must have fixed it, but macOS has not caught up with that ... > The getppid() check is there to close a vanishingly rare race > condition: when creating a WaitEventSet, we ask the kernel to tell us > when the postmaster exits, but there is a possibility that the > postmaster has already exited; normally that causes an error with > errno == ESRCH (no such PID, it's already gone), but another unrelated > process might have started that has the same PID, so we check if our > ppid has changed after a successful return code. That's not going to > work under a debugger on this OS. Irk. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-committers по дате отправления: