Re: BackgroundPsql swallowing errors on windows

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: BackgroundPsql swallowing errors on windows
Date: 2026-02-18 19:41:51
Message-ID: 1880b789-cb54-4162-ae19-9eb29fabc8da@dunslane.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2026-02-17 Tu 4:56 PM, Andres Freund wrote:
> 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.
>
>

I replaced the use of FFI::C with FFI::Platypus::Record. That comes for
free with FFI::Platypus, so there would be no extra dependency. It means
a little extra housekeeping so we don't lose track of the pointer for
later use with PQfreemem, but it's not too bad.

I have tried it out with Windows, seemed to work OK although the
xid_wraparound tests 2 and 3 timed out.

Latest is attached.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Attachment Content-Type Size
Tap-Sessions-v11.patch text/x-patch 206.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2026-02-18 19:57:58 Re: pg_plan_advice
Previous Message Tom Lane 2026-02-18 19:33:02 Re: generating function default settings from pg_proc.dat