Re: conchuela timeouts since 2021-10-09 system upgrade - Mailing list pgsql-bugs

From Thomas Munro
Subject Re: conchuela timeouts since 2021-10-09 system upgrade
Date
Msg-id CA+hUKGJ6XV1D9+L+VK7FLs=4a_mWcZHdNeiVA-o-Z_4T5dCLoQ@mail.gmail.com
Whole thread Raw
In response to Re: conchuela timeouts since 2021-10-09 system upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: conchuela timeouts since 2021-10-09 system upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #17245: Index corruption involving deduplicated entries
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #17245: Index corruption involving deduplicated entries