pgsql: Un-break pg_dump for the case of zero-column tables.

2010/2/24 Tom Lane <tgl@postgresql.org>:

Log Message:
-----------
Un-break pg_dump for the case of zero-column tables.

This was evidently broken by the CREATE TABLE OF TYPE patch.  It would have
been noticed if anyone had bothered to try dumping and restoring the
regression database ...

Is there a point in doing that at the end of "make check"? Or as a
separate step on the buildfarm?

It would at least find problems that cause syntax errors or such
things when loading, even if we don't compare the full data?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:

2010/2/24 Tom Lane <tgl@postgresql.org>:

Log Message:
-----------
Un-break pg_dump for the case of zero-column tables.

This was evidently broken by the CREATE TABLE OF TYPE patch. �It would have
been noticed if anyone had bothered to try dumping and restoring the
regression database ...

Is there a point in doing that at the end of "make check"? Or as a
separate step on the buildfarm?

I think it would make sense to add it as a buildfarm phase, probably
after installcheck not check so you still have a working postmaster.
I'm not sure how easy it'd be to automate though. What I usually do
is make a text dump, restore the dump into an empty DB (watching for
errors), dump that, and diff the two dumps. However the expected
diff is not empty because of some tests that intentionally stress
inheritance column order, and I'm not sure whether it is stable
enough to use a simple expected-result comparison.

Still, if anyone who knows the buildfarm code cares to try that,
I'd be all for it.

regards, tom lane

Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

2010/2/24 Tom Lane <tgl@postgresql.org>:

Log Message:
-----------
Un-break pg_dump for the case of zero-column tables.

This was evidently broken by the CREATE TABLE OF TYPE patch. ���It would have
been noticed if anyone had bothered to try dumping and restoring the
regression database ...

Is there a point in doing that at the end of "make check"? Or as a
separate step on the buildfarm?

I think it would make sense to add it as a buildfarm phase, probably
after installcheck not check so you still have a working postmaster.
I'm not sure how easy it'd be to automate though. What I usually do
is make a text dump, restore the dump into an empty DB (watching for
errors), dump that, and diff the two dumps. However the expected
diff is not empty because of some tests that intentionally stress
inheritance column order, and I'm not sure whether it is stable
enough to use a simple expected-result comparison.

I use that method to test pg_migrator and I always had to edit the dump
to remove a few items that always varied.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com
  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do
  + If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

2010/2/24 Tom Lane <tgl@postgresql.org>:

Log Message:
-----------
Un-break pg_dump for the case of zero-column tables.

This was evidently broken by the CREATE TABLE OF TYPE patch. It would have
been noticed if anyone had bothered to try dumping and restoring the
regression database ...

Is there a point in doing that at the end of "make check"? Or as a
separate step on the buildfarm?

I think it would make sense to add it as a buildfarm phase, probably
after installcheck not check so you still have a working postmaster.
I'm not sure how easy it'd be to automate though. What I usually do
is make a text dump, restore the dump into an empty DB (watching for
errors), dump that, and diff the two dumps. However the expected
diff is not empty because of some tests that intentionally stress
inheritance column order, and I'm not sure whether it is stable
enough to use a simple expected-result comparison.

Still, if anyone who knows the buildfarm code cares to try that,
I'd be all for it.

The code is public and there is nothing very magical about it. Each step
is performed by a perl function. For example, here is the function for
the "make contrib" step:

sub make_contrib
{
# part of build under msvc
return if $skip_steps{'make-contrib'};
my @makeout = `cd $pgsql/contrib && $make 2>&1`;
my $status = $? >>8;
writelog('make-contrib',\@makeout);
print "======== make contrib log ===========\n",@makeout if
($verbose > 1);
send_result('Contrib',$status,\@makeout) if $status;
$steps_completed .= " Contrib";
}

One for this purpose would have to be somewhat more involved than this
example, since we'd need to invent a success measure, which "make"
already gives us for free, and also there are more steps involved than
running a single "make" command. But it should not be terribly
difficult for anyone who wants to try.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

I think it would make sense to add it as a buildfarm phase, probably
after installcheck not check so you still have a working postmaster.
I'm not sure how easy it'd be to automate though. What I usually do
is make a text dump, restore the dump into an empty DB (watching for
errors), dump that, and diff the two dumps. However the expected
diff is not empty because of some tests that intentionally stress
inheritance column order, and I'm not sure whether it is stable
enough to use a simple expected-result comparison.

One for this purpose would have to be somewhat more involved than this
example, since we'd need to invent a success measure, which "make"
already gives us for free, and also there are more steps involved than
running a single "make" command. But it should not be terribly
difficult for anyone who wants to try.

Actually, given the need for an expected-result file, which could be
expected to require maintenance, I suspect that most of the
infrastructure for this would have to go into the core source tree
anyway. Perhaps a "make install-check-pg_dump" target in src/regress?

regards, tom lane