Re: conchuela timeouts since 2021-10-09 system upgrade
От | Thomas Munro |
---|---|
Тема | Re: conchuela timeouts since 2021-10-09 system upgrade |
Дата | |
Msg-id | CA+hUKGJ6XV1D9+L+VK7FLs=4a_mWcZHdNeiVA-o-Z_4T5dCLoQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: conchuela timeouts since 2021-10-09 system upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: conchuela timeouts since 2021-10-09 system upgrade
|
Список | pgsql-bugs |
On Wed, Oct 27, 2021 at 3:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > [...] I'd be prepared to believe that prairiedog's > ancient macOS version has some weird bug preventing kevent() from noticing > available data ... but (a) surely conchuela wouldn't share such a bug, > and (b) we've been using kevent() for a couple years now, so how come > we didn't see this before? There was this case soon after our kqueue support landed: https://www.postgresql.org/message-id/CA%2BhUKGLzaR5cV0EmZWoVXJDO_XwZpmpQX_sYwCBRE1qLBEcGPQ%40mail.gmail.com There are a few discussions on the 'net about the flakiness of both kevent() and poll() around that vintage of macOS (both were new and shared infrastructure, separate from select()); for example in libcurl and libevent talked about this and blocked version ranges. I don't have any ideas about conchuela. For the next person who manages to reproduce this, just to sanity-check what we're passing in to kevent(), what do *port and waitfor look like when secure_read() blocks in WaitEventSetWait? It's good news that Andrey could reproduce this on a VM. I may look into setting one of those up too.
В списке pgsql-bugs по дате отправления: