Re: BackgroundPsql swallowing errors on windows

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: BackgroundPsql swallowing errors on windows
Date: 2026-02-17 00:17:48
Message-ID: 5dgt6vir7n664qruw3ndywpmfxsmfuu4oeh43syocgo3g6v72n@hjxahrqk4w7t
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2026-02-17 00:22:39 Re: Inval reliability, especially for inplace updates
Previous Message Thomas Munro 2026-02-17 00:05:28 Re: AIX support