Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> While doing some tests, I have encountered too many problems with
> incompatible BLKSZ (the backend comipled in different BLKSZ with the
> one in database). I know this is my fault, but it would be nice if
> there is better way to avoid this kind of disaster.
I think this is a fine idea, but BLKSZ is not the only critical
parameter that should be verified at startup. RELSEG_SIZE is
also critical and should be checked the same way. Are there any
other configuration variables that affect database layout? I can't
think of any offhand, but maybe someone else can.
Another thing I would like to see handled in the same way is some sort
of "database layout serial number" that is not the same as the official
version number. During development we frequently make initdb-forcing
changes to the contents of system tables, and sometimes not everyone
gets the word. (I recall Thomas wasted a few hours that way after a
recent change of mine, for example.) We ought to have an internal
version number in some central source file that can be incremented at
any time by anyone who's committing a change that requires initdb.
That would make sure that no one tries to run updated code against an
incompatible database, even if they haven't been paying close attention
to their hackers email. It could save a lot of wasted effort, I think.
regards, tom lane
