Horton

Re: adding a new column in IDENTIFY_SYSTEM

Magnus Hagander <magnus@hagander.net>

View thread
From: Magnus Hagander <magnus@hagander.net>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jaime Casanova <jaime@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-05-05T15:54:01Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add postmaster/postgres undocumented -b option for binary upgrades.

  2. Add casts from int4 and int8 to numeric.

  3. Oops, forgot to bump catversion in the Serializable Snapshot Isolation patch.

On Wed, May 4, 2011 at 22:42, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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?

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/