Re: adding a new column in IDENTIFY_SYSTEM - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: adding a new column in IDENTIFY_SYSTEM
Date
Msg-id BANLkTin=X2-=5h1E_Y_Se=Lvbff3QWyNxg@mail.gmail.com
Whole thread Raw
In response to Re: adding a new column in IDENTIFY_SYSTEM  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: adding a new column in IDENTIFY_SYSTEM  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Wed, May 4, 2011 at 3:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jaime Casanova <jaime@2ndquadrant.com> writes:
>> I want to propose the addition of a new field in IDENTIFY_SYSTEM:
>> xlogversion, which will carry XLOG_PAGE_MAGIC from primary.
>> The idea of sending that info is to allow us to know if the xlog page
>> version of two different major versions are compatible or not.
>> Currently pg_upgrade requires the primary to be taken down,
>
> That's *intentional*.
>
> The notion of WAL-shipping-replication compatibility between two
> different major versions is insane on its face.  They will not have
> compatible system catalog contents.  You might get perfect replication
> of the master's catalogs, but the slave wouldn't be able to interpret
> them.

That's exactly how hard in place upgrade was to begin with.

Considering how valuable this would be, it seems worth it to pursue this.

> The reason we have XLOG_PAGE_MAGIC is really more the opposite: to
> prevent people from trying to recover across a minor version update in
> which we had to break XLOG compatibility.  I don't recall right now
> if that's ever actually happened, but it definitely could.

If that is true, then allowing this patch will allow us to detect that
incompatibility when the standby connects to the master, and explain
the issue in a useful error message. Otherwise we will just barf on
the magic value.

Having access to these details might make it possible to upgrade. They
could be inferred, but it would be better to have the full data so we
can take an informed decision about whether or not it is possible.

So even if people don't believe in the rationale behind the patch,
would allowing it harm anything at this point?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: VARIANT / ANYTYPE datatype
Next
From: "Kevin Grittner"
Date:
Subject: Re: Predicate locking