Re: Using LibPq in TAP tests via FFI
От | Andrew Dunstan |
---|---|
Тема | Re: Using LibPq in TAP tests via FFI |
Дата | |
Msg-id | f84b8765-49c5-4759-bc9f-ea69e2c0c448@dunslane.net обсуждение исходный текст |
Ответ на | Re: Using LibPq in TAP tests via FFI (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Using LibPq in TAP tests via FFI
|
Список | pgsql-hackers |
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@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? 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
Вложения
В списке pgsql-hackers по дате отправления: