Re: Using LibPq in TAP tests via FFI

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Using LibPq in TAP tests via FFI
Date: 2024-06-16 22:38:30
Message-ID: 20240616223830.hhdtxy57sywemnad@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2024-06-16 22:48:13 Re: Conflict Detection and Resolution
Previous Message Tomas Vondra 2024-06-16 22:23:34 Re: assertion failure at cost_memoize_rescan()