Re: pgsql: Introduce new page checksum algorithm and module.

On Mon, April 29, 2013 11:03, Simon Riggs wrote:
> On 29 April 2013 09:28, Erikjan Rijkers <er(at)xs4all(dot)nl> wrote:
>> On Mon, April 29, 2013 10:08, Simon Riggs wrote:
>>> Introduce new page checksum algorithm and module.
>>
>> I get these errors (but on an existing database), so apparently a catversion bump was needed?
>
> You noticed I had committed, upgraded your database, which was running
> a non-default option using alpha code, ran tests on it and wrote an
> email back, all within 20 min?
>
> I take it this is just a test and the point is just a theoretical one
> based on an automated test suite? I'm not sure that we test for
> upgrade compatibility anywhere in the community tests.
>
> Would you care to share your test suite with the community, it sounds useful.
>
> Thanks for the report.
>

Well, when I see a commit (via email), I do a pull and I look if it needs initdb on the basis of
the two variables below (catalog_version and control_version); if an initdb is not needed, I
immediately (but not automatically) compile it underneath my dev database - after all,
compile-check-install only takes a couple of minutes.

So really, the automaton is me ;-)

Because of the errors, I assumed that an initdb is needed and therefore a catversion bump was
missing. But that is guesswork on my part; maybe there is something else.

I suppose a non-initdb recompile could be automated on the basis of these two:

catalog_version=$( grep CATALOG_VERSION_NO $dir/src/include/catalog/catversion.h | cut -f 2 );

and

control_version=$( grep -h define.PG_CONTROL_VERSION $dir/src/include/catalog/pg_control.h | cut
-f 2 );

where $dir points to the src tree at hand.

So I have no further test-suite, I'm afraid, and the monster bash-script that compiles instances
from patches is too horrible to inflict on others...

Thanks,

Erik Rijkers