pgsql: Disable BLOB test in pg_dump TAP tests

Stephen Frost <sfrost@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.

I think it's probably best not to monkey with it right now, but after
beta1 is out, we should try re-enabling it.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@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&amp;dt=2016-05-06%2023%3A41%3A15&amp;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

On 05/08/2016 12:52 AM, Stephen Frost wrote:

Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@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&amp;dt=2016-05-06%2023%3A41%3A15&amp;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.

TL;DR version: Msys provides a virtualized Unix-like file system that is
visible to its programs that you use to build, but invisible to the
programs you build since they are going to run without any knowledge of
the build environment. So you can't just put $tmpdir from an Msys-aware
program into a psql script and expect it to work. It won't. Maybe we
need to provide a function in our test library to convert virtual paths
to real paths. (For Unix it would be a NOOP).

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Andrew Dunstan (andrew@dunslane.net) wrote:

TL;DR version: Msys provides a virtualized Unix-like file system
that is visible to its programs that you use to build, but invisible
to the programs you build since they are going to run without any
knowledge of the build environment. So you can't just put $tmpdir
from an Msys-aware program into a psql script and expect it to work.
It won't. Maybe we need to provide a function in our test library to
convert virtual paths to real paths. (For Unix it would be a NOOP).

I'm pretty confident that I can work around this for the specific test
that was having trouble, but it seems like it'd be nice to have a way to
refer to the actual data and temp directories from psql and friends when
they're run under the TAP test system.

Ideally, there'd be a way to make it transparent, so we don't have to
write the tests to handle this case explicitly, though I'm not sure if
there's an easy way to do that.

Thanks!

Stephen