Re: adding a new column in IDENTIFY_SYSTEM

On Wed, May 4, 2011 at 22:42, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Wed, May 4, 2011 at 3:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Jaime Casanova <jaime(at)2ndquadrant(dot)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?

Adding it for the sake of upgrades seems very far fetched.

Adding it for the sake of giving a better error message seems like a
very good idea. But in that case, the client side code to actually
give a better error message should be included from the start, IMHO.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/