> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Thursday, June 10, 2004 2:19 PM
> To: Manfred Koizar
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] More vacuum.c refactoring
>
>
> Manfred Koizar <mkoi-pg@aon.at> writes:
> > This code is very similar to vacuum_page(). The major
> difference is
> > that vacuum_page() uses vacpage->offsets while the code in
> > repair_frag() looks for MOVED_OFF bits in tuple headers.
> AFAICS the
> > tuples with the MOVED_OFF bit set are exactly those referenced by
> > vacpage->offsets.
>
> This does not make me comfortable. You *think* that two
> different bits of code are doing the same thing, so you want
> to hack up vacuum.c? This module is delicate code --- we've
> had tons of bugs there in the past
> --- and no I have zero confidence that passing the regression
> tests proves anything, because all those prior bugs passed
> the regression tests.
Then why didn't those bugs get added to the regression? That has been
standard procedure in every place that I have ever worked.
We have 7000+ tests in our CONNX regression suite that take one week to
run, on an array of dozens of computers from micros to mainframes.
Besides finding quickly if you have reintroduced a problem, it will also
ferret out lots of newly introduced problems.
It seems that MySQL has some sort of extensive test, from looking at
their site. Maybe the Pgsql group could simply cannibalize it.
Perhaps your regression test is really a sanity check, rather than a
regression test. After all, the meaning of 'regression' itself demands
that you introduce new tests based upon old failures.
I seem to recall that someone was porting the NIST suite to PostgreSQL.
What ever happened to that effort?
