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

From Andres Freund
Subject Re: BackgroundPsql swallowing errors on windows
Date
Msg-id tir2xsciqfiypagzortygjrwaomwdflbw3tjpz7iji2pefxye7@wkgxlxm7e2bg
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-17 16:31:02 -0500, Andrew Dunstan wrote:
> On 2026-02-16 Mo 7:17 PM, Andres Freund wrote:
> > 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.
> >

> Try this version. On my machine it's now a few percent faster. I fixed the
> polling. I also added pipeline support for large sets of commands, to
> minimize roundtrips.

Nice!  Will try it out.


Have you tried it on windows already? That's where we pay by far the biggest
price due to all the unnecessary process creations...

It looks like strawberry perl has FFI::Platypus, but not FFI::C.  There is
perl/vendor/lib/FFI/Platypus/Lang/C.pm, but that just seems like it's
documentation.  There is however FFI::Platypus::Record, which maybe could
suffice?

Do we actually need FFI::C, or can we work around not having it? Looks like
it's just used for notify related stuff.

It looks like mingw doesn't have packages for FFI::Platypus, but it'll
probably be a lot easier to build that than when using msvc.


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: index prefetching
Next
From: Tom Lane
Date:
Subject: Re: generating function default settings from pg_proc.dat