| 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-06-10 20:23:47 |
| Message-ID: | 506de8d3-e2b1-4929-88d8-96253d5e4121@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-06-03 We 5:23 PM, Andrew Dunstan wrote:
>
> On 2026-06-02 Tu 3:03 PM, Andrew Dunstan wrote:
>>
>> On 2026-02-18 We 2:41 PM, Andrew Dunstan wrote:
>>>
>>> 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.
>>>
>>>
>>>
>>
>> Here is v12. I removed the XS variant in this version, which makes
>> things simpler. We can restore it if necessary.
>>
>> Patch 1 adds the new framework
>>
>> Patch 2 adapts Cluster.pm to it, as well as handling some instability
>> at global destruction time that was exacerbated by using FFI::Platypus.
>>
>> Patch 3 makes improvements in the individual TAP tests using the
>> framework, including removing every one of the calls to
>> background_psql().
>>
>>
>> I'm going to add this to the CF and will start testing (again) on
>> Windows.
>>
>>
>>
>
> v13 attached now passes all tests on my Windows machine.
>
>
>
rebased, including porting a new use of background_psql.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| v14-0001-Add-PostgreSQL-Test-Session-for-libpq-based-TAP-.patch | text/x-patch | 59.8 KB |
| v14-0002-Use-PostgreSQL-Test-Session-within-the-TAP-test-.patch | text/x-patch | 6.9 KB |
| v14-0003-Convert-TAP-tests-to-PostgreSQL-Test-Session.patch | text/x-patch | 174.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-06-10 20:29:20 | Re: Move system identifier generation to a common helper |
| Previous Message | Alexander Lakhin | 2026-06-10 20:00:00 | Re: Why our Valgrind reports suck |