Re: Sigh, we need an initdb

On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On 06/04/2014 03:50 PM, Robert Haas wrote:
>> On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I just noticed that we had not one, but two commits in 9.4 that added
>>> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
>>> This is inexcusable sloppiness on the part of the committers involved,
>>> but the question is what do we do now?
>>
>> I think it would be an awfully good idea to think about what we could
>> put into the buildfarm, the git repository, or the source tree to get
>> some automatic notification when somebody screws up this way (or the
>> xlog header magic, or catversion). The first of those two screw-ups
>> (by me) was 11 months ago today; it's pretty scary that we're only
>> just now noticing.
>>
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company