From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <thomas(at)fourpalms(dot)org> |
Cc: | PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_control contents |
Date: | 2002-03-22 17:17:53 |
Message-ID: | 2155.1016817473@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <thomas(at)fourpalms(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-03-22 17:19:15 | Re: Problem with reloading groups in pg_hba.conf |
Previous Message | Fernando Nasser | 2002-03-22 16:54:19 | Re: SET NULL / SET NOT NULL |