On 2024-Jul-16, Alexander Lakhin wrote:
> I've managed to reproduce this issue in my Cygwin environment by running
> the postgres_fdw test in a loop (10 iterations are enough to get the
> described effect). And what I'm seeing is that a query-cancelling backend
> is stuck inside pgfdw_xact_callback() -> pgfdw_abort_cleanup() ->
> pgfdw_cancel_query() -> pgfdw_cancel_query_begin() -> libpqsrv_cancel() ->
> WaitLatchOrSocket() -> WaitEventSetWait() -> WaitEventSetWaitBlock() ->
> poll().
>
> The timeout value (approximately 30 seconds), which is passed to poll(),
> is effectively ignored by this call — the waiting lasts for unlimited time.
Ugh. I tried to follow what's going on in that cygwin code, but I gave
up pretty quickly. It depends on a mutex, but I didn't see the mutex
being defined or initialized anywhere.
> So it looks like a Cygwin bug, but maybe something should be done on our side
> too, at least to prevent such lorikeet failures.
I don't know what else we can do other than remove the test.
Maybe we can disable this test specifically on Cygwin. We could do that
by creating a postgres_fdw_cancel.sql file, with the current output for
all platforms, and a "SELECT version() ~ 'cygwin' AS skip_test" query,
as we do for encoding tests and such.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Doing what he did amounts to sticking his fingers under the hood of the
implementation; if he gets his fingers burnt, it's his problem." (Tom Lane)