Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > Disable BLOB test in pg_dump TAP tests > > > Buildfarm member jacana appears to have an issue with running this > > test. It's not entirely clear to me why, but rather than try to > > fight with it, just disable it for now. > > BTW, what was your evidence for thinking that that specific test > needed to be disabled? It looks to me like it would have been > subject to the $-in-/m-mode bug we identified today, so I'm wondering > if it was merely the first to fail.
No, those errors were "match/don't match" errors. At the bottom of: http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=jacana&dt=2016-05-06%2023%3A41%3A15&stg=bin-check is the error, which is 'No such file or directory'. I'm pretty sure the error is from the '\o' in that test which is trying to write a file to the '$tempdir' directory. Clearly, on that system at least, $tempdir isn't a completely fully-qualified path, since it ends up being: /home/pgrunner/bf/root/HEAD/pgsql.build/src/bin/pg_dump/tmp_check/tmp_test_v8cH but the data directory is: c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.build/src/bin/pg_dump/tmp_check/data_main_NSG0/pgdata I'm not quite sure how that system works (is a starting '/' actually referring to a relative path, and psql isn't being run from that root directory? Or does the shell handle converting arguments which start with a '/' to their full path, and that's why calls to pg_ctl and other things work, but trying to use that same path from inside a program doesn't?), but apparently referring to $tempdir from inside psql doesn't give you the same directory that referring to it from the TAP perl script does. > I think it's probably best not to monkey with it right now, but after > beta1 is out, we should try re-enabling it. I'd definitely like to work on getting that test working everywhere post-beta1, but the simplest answer will probably be to just load the large-object in the same way that pg_dump dumps it out, namely using the 'lo_open', 'lo_write', 'lo_close' functions. The goal of that test is to make sure that pg_dump does the right thing when it comes to exporting the large object, not to test that \lo_import of psql works (though that would certainly be a good thing to test in a set of psql tests...). Thanks! Stephen
signature.asc
Description: Digital signature
