Re: BackgroundPsql swallowing errors on windows - Mailing list pgsql-hackers

From Andres Freund
Subject Re: BackgroundPsql swallowing errors on windows
Date
Msg-id 5dgt6vir7n664qruw3ndywpmfxsmfuu4oeh43syocgo3g6v72n@hjxahrqk4w7t
Whole thread
In response to Re: BackgroundPsql swallowing errors on windows  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: BackgroundPsql swallowing errors on windows
List pgsql-hackers
Hi,

On 2026-02-16 16:38:02 -0500, Andrew Dunstan wrote:
> Here we are almost exactly a year later. I returned to this work quite
> recently, and reached a milestone, namely the removal of all calls to
> BackgroundPsql, with all the TAP tests passing. The XS module still has some
> problems, and I think I'm inclined not to pursue it, and just rely on the
> FFI mapping.
> 
> The current state of this is attached. People who are interested can hit me
> up for info in Vancouver if not before. I'll work on turning this into a set
> of commitable patches.

Nice progress!

I briefly tried this out. The overall resource usage of the test is noticeably
reduced - and that's on linux with fast fork, so it should be considerably
better on windows.  However, the tests take a lot longer than before, I think
mostly due to polling for results rather than waiting for them to be ready
using PQsocketPoll() or such.

E.g. bloom/001_wal takes about 15s on HEAD for me, but 138s with the patch. I
think that's just due to the various usleep(100_000);


FWIW, oauth_validator/001_server fails with the patch at the moment.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: AIX support
Next
From: Noah Misch
Date:
Subject: Re: Inval reliability, especially for inplace updates