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
