Re: Planning incompatibilities for Postgres 10.0 - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Planning incompatibilities for Postgres 10.0
Date
Msg-id 51A227B2.8070602@agliodbs.com
Whole thread Raw
In response to Planning incompatibilities for Postgres 10.0  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Planning incompatibilities for Postgres 10.0  (Stephen Frost <sfrost@snowman.net>)
Re: Planning incompatibilities for Postgres 10.0  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
> 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*.  We
don't have a complete spec at this point, let alone a development plan,
and it's entirely possible that we'll be able to implement SMs without
breaking pgupgrade.

It's also not at all clear that we can develop SMs in less than 2 years.I tend to think it unlikely.

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.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: View Index and UNION
Next
From: Josh Berkus
Date:
Subject: Re: Processing long AND/OR lists