Re: [COMMITTERS] pgsql: Disable BLOB test in pg_dump TAP tests

Tom,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)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