Re: pg_control contents - Mailing list pgsql-hackers

> > 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.

Got all that the first time. You are saying what *should* happen wrt
bumping version numbers when resizing those string fields, but that
isn't the point at all. *If* that doesn't happen, we should gracefully
give as much information as possible about the *nature* of the problem.
Just because the CRC fails doesn't mean that there are some clues inside
the file as to why, or what it would take to fix the problem.

If LOCALE_NAME_BUFLEN changes size between writing and reading the
control file, the CRC *could* still be calculated correctly. Currently
that is not the case, but that doesn't mean that we have an ideal
implementation at the moment.

> 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.

I don't agree that detailed information in the same style as other
information is a guarantee of future trouble; in some circles consistant
approaches are used to avoid other possible trouble. I'm not much
interested in fighting Yet Another Issue for this case. Will revert to
the current scheme of incremental integer number but would be willing to
discuss this at some future date if it comes up again.
                  - Thomas