Thomas Lockhart <thomas@fourpalms.org> writes:
> OK, I'll add NAMEDATALEN, FUNC_MAX_ARGS, and LOCALE_NAME_BUFLEN. Any
> more?
No, you're missing my point: there is zero value in adding
LOCALE_NAME_BUFLEN as an explicit field in ControlFileData.
The entire physical layout of ControlFileData has to be implicit in
PG_CONTROL_VERSION, because that is the only field we can reasonably
check before computing the CRC --- and if we don't have the correct
sizeof(ControlFileData), the CRC check will surely fail. Therefore,
any change in LOCALE_NAME_BUFLEN would have to be signaled by bumping
PG_CONTROL_VERSION, *not* by any change in some other field inside
ControlFileData. Look at the code that reads and validates pg_control
in xlog.c.
If there are other configurable parameters that can affect the format of
system catalogs, then by all means let's add 'em. Nothing comes to mind
however.
>> Don't forget to bump PG_CONTROL_VERSION.
> I'd like to change this to the yyyymmddN format used in the catalog
> version number (it is currently an integer set to ~71). It should make
> it much easier to guess at code vintages from problem reports (if
> nothing else), right?
Actually, I deliberately did not use yyyymmdd for PG_CONTROL_VERSION,
because I wanted it to be absolutely not confusable with
CATALOG_VERSION_NO. I took the then major version number as being
probably sufficient --- I do not foresee us revising pg_control's layout
very often, certainly less than once per release.
If you want to change it to yyyyN (eg, 20021 for this change) I won't
object. But let's not use a convention that makes it look just like
CATALOG_VERSION_NO. I think that'd be a recipe for confusion.
regards, tom lane
