Re: Planning incompatibilities for Postgres 10.0

On 05/26/2013 06:18 PM, Josh Berkus wrote:
>> 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.
> Isn't this a bit of horse-cart inversion here? We just hashed out a
> tentative, incomplete pseudo-spec for storage managers *yesterday*.
Many people have been *thinking* about pluggable storage /
storage managers for much longer time.
> We
> don't have a complete spec at this point, let alone a development plan,
I think we will have a development plan *before* complete spec
anyway :)
> and it's entirely possible that we'll be able to implement SMs without
> breaking pgupgrade.
My point was exactly to not spend majority of new storage manager
discussion on "does it break pg_upgrade", "maybe we can find a way
to do it without breaking pg_upgrade", etc...
> It's also not at all clear that we can develop SMs in less than 2 years.
> I tend to think it unlikely.
I think the important part of Simons message was not "two years"
> First, let's have a few features for which breaking binary compatibility
> is a necessity or a clear benefit. Then we'll schedule when to break them.
But rather than "it breaks pg_upgrade" not being a complete stopper for
proposed useful features that might break it.

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