Prev: [HACKERS] Did we really want to force an initdb in beta2?
Next: [pgsql-hackers] Daily digest v1.10705 (13 messages)
From: Robert Haas on 4 Jun 2010 11:22
On Fri, Jun 4, 2010 at 11:06 AM, Dave Page <dpage(a)pgadmin.org> wrote:
> On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> Bruce Momjian <bruce(a)momjian.us> writes:
>>> Dave Page wrote:
>>>> Shouldn't we have bumped the catversion? The installers can't tell
>>>> that beta1 clusters won't work with beta2 :-(
>>
>>> That is an interesting point.  Tom bumped the pg_control version, but
>>> not the catalog version.
>>
>> Right, because the catalog contents didn't change.  Seems to me you'd
>> better teach the installers to look at PG_CONTROL_VERSION too.
>
> Hmm, is there anything else that might need to be checked?

XLOG_PAGE_MAGIC, for one. PG_PAGE_LAYOUT_VERSION doesn't change very
often, but might also fall into the same category.

Tablespace directory paths depend on the value of PG_MAJORVERSION.

It would be nice to have all of these documented somewhere along with
the criteria for bumping each one. It's relatively easy for a new
committer (ahem) to not realize that there's a version number that
needs to be bumped someplace, and recent experience has shown that
even an experienced committer can goof. :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 4 Jun 2010 11:30
Dave Page <dpage(a)pgadmin.org> writes:
> On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> Right, because the catalog contents didn't change. �Seems to me you'd
>> better teach the installers to look at PG_CONTROL_VERSION too.

> Hmm, is there anything else that might need to be checked?

Offhand I can think of three internal version-like numbers:

CATALOG_VERSION_NO --- bump if initial system catalog contents would be
inconsistent with backend code

PG_CONTROL_VERSION --- bump when contents of pg_control change

XLOG_PAGE_MAGIC --- bump on incompatible change in WAL contents

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Bruce Momjian on 4 Jun 2010 11:32
Tom Lane wrote:
> Dave Page <dpage(a)pgadmin.org> writes:
> > On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> >> Right, because the catalog contents didn't change. �Seems to me you'd
> >> better teach the installers to look at PG_CONTROL_VERSION too.
>
> > Hmm, is there anything else that might need to be checked?
>
> Offhand I can think of three internal version-like numbers:
>
> CATALOG_VERSION_NO --- bump if initial system catalog contents would be
> inconsistent with backend code
>
> PG_CONTROL_VERSION --- bump when contents of pg_control change
>
> XLOG_PAGE_MAGIC --- bump on incompatible change in WAL contents

pg_upgrade never views these in their raw format so does not need to
check them. (It does look at pg_controldata text output.)

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 4 Jun 2010 11:46
Robert Haas <robertmhaas(a)gmail.com> writes:
> It would be nice to have all of these documented somewhere along with
> the criteria for bumping each one.

Go for it. I think you have all the raw data in this thread.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Bruce Momjian on 4 Jun 2010 09:27
Dave Page wrote:
> On Thu, Jun 3, 2010 at 11:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> > Florian Pflug <fgp(a)phlo.org> writes:
> >> On Jun 3, 2010, at 19:00 , Tom Lane wrote:
> >>> Maybe we should just get rid of the hint.
> >
> >> FYI, Robert Haas suggested the same in the thread that lead to this patch being applied. The arguments against doing that is that a real crash during recovery *is* something to be quite alarmed about.
> >
> > After some discussion among core we're going to leave it as-is. ?Anybody
> > who doesn't want to initdb for beta2 can test out pg_upgrade ;-)
>
> Shouldn't we have bumped the catversion? The installers can't tell
> that beta1 clusters won't work with beta2 :-(

That is an interesting point. Tom bumped the pg_control version, but
not the catalog version. I am unclear how that affects people's
visibility about incompatibility. (pg_upgrade will not care.)

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [HACKERS] Did we really want to force an initdb in beta2?
Next: [pgsql-hackers] Daily digest v1.10705 (13 messages)