Re: Sigh, we need an initdb

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Sigh, we need an initdb
Дата
Msg-id 16510.1401924194@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Sigh, we need an initdb  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Sigh, we need an initdb
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Sigh, we need an initdb
Следующее
От: Andres Freund
Дата:
Сообщение: slotname vs slot_name