Re: Planning incompatibilities for Postgres 10.0

On 05/26/2013 04:22 PM, Bruce Momjian wrote:
> On Sun, May 26, 2013 at 09:18:11AM -0400, Bruce Momjian wrote:
>> On Sun, May 26, 2013 at 10:53:37AM +0100, Simon Riggs wrote:
>>>> I consider this thread to be not thought-through, obviously.
>>> My proposal has had lots of serious consideration, but that is not the
>>> topic of this thread.
>>>
>>> The title of the thread is a general one, with a clear objective.
>>>
>>> I'm looking for a way forwards that allows us to introduce the changes
>>> that many have proposed and which regrettably result in
>>> incompatibilities. If we have no plan I think its likely it will never
>>> happen and it is currently blocking useful change.
>>>
>>> Please explain what you consider to be a better plan, so we can judge
>>> all proposals together.
>> I agree with the idea of using logical replication as a way to do
>> pg_upgrade version-breaking releases. What I don't know is what
>> incompatible changes are pending that would require this.
> Sorry I was unclear. When I said "not thought-through", I meant, you
> need to start with the _reason_ we need to break pg_upgrade in an
> upcoming version, then we can start to plan how to do it. The logical
> replication idea is a good one for getting us through pg_upgrade
> version-breaking releases.
>
> I am fine with breaking pg_upgrade, but I just don't see the pending
> reason at this point.
Not sure which ones Simon meant, but at least any new/better
storage manager would seem to me to be requiring
a non-pg_upgrade upgrade path unless we require the storage manager
to also include a parallel implementation of pg_upgrade.

The family of possible storage magers here would include column stores,
distributed / partitioned / replicated memory-only / index-structured / ...
storages which all could have advantages in certain situations and whic
all
need an upgrade path.

While you could do this using sequance of first pg_upgrading and then doing
some internal data migration to new storage manager doing this in one go
would be much smoother.

--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ