Re: adding a new column in IDENTIFY_SYSTEM

From: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: adding a new column in IDENTIFY_SYSTEM
Date: 2011-05-15 23:03:32
Message-ID: BANLkTi=gmahi6Pbg_COKnRWgYf54xrmmBw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 5, 2011 at 10:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> 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.
>
> What's not apparent to me is how we'll even get to this check; if
> there's a mismatch, won't the database system identifier comparison
> fail first in most scenarios?
>

that's why i didn't propose that to begin with... but thinking on
that, we can use it to add a message in pg_basebackup, maybe just a
warning if we are taking a basebackup from an incompatible system...

but for that i will need to add xlog_internal.h and postgres.h to
pg_basebackup and use the "#define FRONTEND 1" hack we have in
pg_resetxlog

> I'm also wondering why send WAL version number and not, say, catalog
> version number, if there's some idea that we need more tests than the
> system identifier comparison.
>

well... catversion is not that informative, we change it for a lot of
reasons, not only catalog estructure changes... so we can't swear that
xlog records will be incompatible just because catversion changes...

but yes, we need to know if catalog estructure has changed, maybe we
can change XLOG_PAGE_MAGIC when that happens?

> Given reasonable answers to these questions, I'd not object to putting
> in additional error testing.  I concur with Magnus that the patch should
> actually provide those tests, and not just put in an unused field.
>

actually, now is when we can play with that API at will when/if we can
make online upgrades work then we will be stuck with whatever we have
made. before that we know it won't affect anybody

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2011-05-15 23:43:43 Re: DOMAINs and CASTs
Previous Message Cédric Villemain 2011-05-15 21:38:57 cache estimates, cache access cost