Re: Using LibPq in TAP tests via FFI

On 2024-06-16 Su 6:38 PM, Andres Freund wrote:
> 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?

Not sure, that code was written months ago. I just checked the
FFI::CheckLib code and libpath is searched before systempath, so there
shouldn't be any reason not to use the default load path.

>
> 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]

Yeah, the recovery tests were using poll_query_until in a rather funky
way. That's fixed in this latest version.

>
>
>
>> 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...
>
>

Maybe not. If so your other suggestion of a small XS wrapper might make
sense.

cheers

andrew

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