During the development of an unrelated feature, I have experienced
failures in a pg_dump test case, specifically
t/002_pg_dump.pl ....... 1825/6052
# Failed test 'defaults_parallel: should not dump COPY
fk_reference_test_table second'
# at t/002_pg_dump.pl line 3454.
This test sets up two tables connected by a foreign key and checks that
a data_only dump dumps them ordered so that the primary key table comes
first.
But because of the way the tests are set up, it also checks that in all
other dumps (i.e., non-data_only) it does *not* dump them in that order.
This is kind of irrelevant to the test, but there is no way to express
in the pg_dump tests to not check certain scenarios.
In a non-data_only dump, the order of the tables doesn't matter, because
the foreign keys are added at the very end. In parallel dumps, the
tables are in addition sorted by size, so the resultant order is
different from a single-threaded dump. This can be seen by comparing
the dumped TOCs of the defaults_dir_format and defaults_parallel cases.
But it all happens to pass the tests right now.
In my hacking I have added another test table to the pg_dump test set,
which seems to have thrown off the sorting and scheduling, so that the
two tables now happen to come out in primary-key-first order anyway,
which causes the test to fail.
I have developed the attached rough patch to add a third option to
pg_dump test cases: besides like and unlike, add a "skip" option to
disregard the result of the test.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
