Re: Using LibPq in TAP tests via FFI - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Using LibPq in TAP tests via FFI
Date
Msg-id 20240616223830.hhdtxy57sywemnad@awork3.anarazel.de
Whole thread Raw
In response to Re: Using LibPq in TAP tests via FFI  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Using LibPq in TAP tests via FFI
Re: Using LibPq in TAP tests via FFI
List pgsql-hackers
Hi,

On 2024-06-16 17:43:05 -0400, Andrew Dunstan wrote:
> On Fri, Jun 14, 2024 at 12:25 PM Andres Freund <andres@anarazel.de> wrote:
> I guess it's a question of how widely available FFI::Platypus is. I know
> it's available pretty much out of the box on Strawberry Perl and Msys2'
> ucrt perl.

FWIW I hacked a bit on CI, trying to make it work. Took a bit, partially
because CI uses an older strawberry perl without FFI::Platypus. And
FFI::Platypus didn't build with that.


Updating that to 5.38 causes some complaints about LANG that I haven't hunted
down, just avoided by unsetting LANG.


As-is your patch didn't work, because it has "systempath => []", which caused
libpq to not load, because it depended on things in the system path...


What's the reason for that?

After commenting that out, all but one tests passed:

[20:21:31.137] ------------------------------------- 8< -------------------------------------
[20:21:31.137] stderr:
[20:21:31.137] #   Failed test 'psql connect success'
[20:21:31.137] #   at C:/cirrus/src/test/recovery/t/041_checkpoint_at_promote.pl line 161.
[20:21:31.137] #          got: '2'
[20:21:31.137] #     expected: '0'
[20:21:31.137] #   Failed test 'psql select 1'
[20:21:31.137] #   at C:/cirrus/src/test/recovery/t/041_checkpoint_at_promote.pl line 162.
[20:21:31.137] #          got: ''
[20:21:31.137] #     expected: '1'
[20:21:31.137] # Looks like you failed 2 tests of 6.
[20:21:31.137]
[20:21:31.137] (test program exited with status code 2)
[20:21:31.137] ------------------------------------------------------------------------------
[20:21:31.137]


Due to concurrency and run-to-run variance I wouldn't bet too much on this,
but the modified tests do have improved test times:

before:

[19:40:47.468] 135/296 postgresql:pg_amcheck / pg_amcheck/004_verify_heapam                            OK
7.70s   32 subtests passed
 
[19:43:40.853] 232/296 postgresql:amcheck / amcheck/001_verify_heapam                                  OK
36.50s  272 subtests passed
 

after:
[20:22:55.495] 133/296 postgresql:pg_amcheck / pg_amcheck/004_verify_heapam                            OK
4.60s   32 subtests passed
 
[20:25:13.641] 212/296 postgresql:amcheck / amcheck/001_verify_heapam                                  OK
4.87s   272 subtests passed
 


I looked at a few past runs and there never were instances of
amcheck/001_verify_heapam that were even close to as fast as this.


The overall tests time did improve some, but that is hard to weigh due to the
test failure.


> I agree with you that falling back on BackgroundPsql is not a terribly
> satisfactory solution.

I'm somewhat doubtful we'll just agree on making FFI::Platypus a hard
dependency, but if we agree to do so...


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: assertion failure at cost_memoize_rescan()
Next
From: Tomas Vondra
Date:
Subject: Re: Conflict Detection and Resolution