Re: Sigh, we need an initdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Sigh, we need an initdb
Date
Msg-id 16510.1401924194@sss.pgh.pa.us
Whole thread Raw
In response to Re: Sigh, we need an initdb  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Sigh, we need an initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> I agree it's scary but in a few minutes thinking about it I haven't been
>> able to come up with a good way of checking it. Maybe we could build
>> sizeof(ControlData) into the version number, so instead of 937 we'd have
>> 937nnnnn. Then we could check the nnnnn against what we know we is the size.
>> I realize this isn't perfect, but might be better than nothing.

> I think that's worth considering.  Another idea is: suppose we set up
> a PostgreSQL database somewhere that contained information about what
> controldata layout corresponded to what control version:

> CREATE TABLE control_formats (version_number integer, data_types text[]);

> Every time it runs, it checks out the latest source code.  It checks
> whether the control version is already present in the table; if so, it
> verifies that the data types match.  If they don't, it makes something
> turn red.  If the control version isn't present yet, it inserts
> whatever types it sees as the definitive record of what the new
> version number means.

That seems possibly workable.  Merely checking sizeof(ControlData) isn't
real helpful since (1) it might not catch field additions because of
alignment padding, and (2) it's not clear that that number is, or should
be, entirely architecture-independent.  But I think a list of the C data
type names of the fields (and maybe the fields' own names, for good
measure) would be reasonably robust.

Not sure how we'd scale this idea to catversion or WAL version, but
I think both of those are less significant hazards.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Sigh, we need an initdb
Next
From: Andres Freund
Date:
Subject: slotname vs slot_name