Re: Catalog/Metadata consistency during changeset extraction from wal - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Catalog/Metadata consistency during changeset extraction from wal
Date
Msg-id 4FE86CBE0200002500048AB2@gw.wicourts.gov
Whole thread Raw
In response to Re: Catalog/Metadata consistency during changeset extraction from wal  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Catalog/Metadata consistency during changeset extraction from wal  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Catalog/Metadata consistency during changeset extraction from wal  (Andres Freund <andres@2ndquadrant.com>)
Re: Catalog/Metadata consistency during changeset extraction from wal  (David Fetter <david@fetter.org>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> wrote:
>> We most particularly *don't* want DDL to replicate automatically,
>> because the schema changes are deployed along with related
>> software changes, and we like to pilot any changes for at least a
>> few days.  Depending on the release, the rollout may take a
>> couple months, or we may slam in out everywhere a few days after
>> the first pilot deployment.
> Thats a sensible for your use-case - but I do not think its thats
> the appropriate behaviour for anything which is somewhat
> out-of-the box...
Right.  We currently consider the issues involved in a change and
script it by hand.  I think we want to continue to do that.  The
point was that, given the variety of timings and techniques for
distributing schema changes, maybe is was only worth doing that
automatically for the most constrained and controlled cases.
>> So you could certainly punt all of this for any release as far as
>> Wisconsin Courts are concerned.  We need to know table and column
>> names, before and after images, and some application-supplied
>> metadata.
> I am not sure were going to get all that into 9.3.
Sure, that was more related to why I was questioning how much these
use cases even *could* integrate -- whether it even paid to
*consider* these use cases at this point.  Responses from Robert and
you have pretty much convinced me that I was being overly
pessimistic on that.
One fine point regarding before and after images -- if a value
doesn't change in an UPDATE, there's no reason to include it in both
the BEFORE and AFTER tuple images, as long as we have the null
column bitmaps -- or some other way of distinguishing unchanged from
NULL.  (This could be especially important when the unchanged column
was a 50 MB bytea.)  It doesn't matter to me which way this is
optimized -- in our trigger-based system we chose to keep the full
BEFORE tuple and just show AFTER values which were distinct from the
corresponding BEFORE values, but it would be trivial to adapt the
code to the other way.
Sorry for that bout of pessimism.
-Kevin


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: new --maintenance-db options
Next
From: Robert Haas
Date:
Subject: Re: new --maintenance-db options