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

From Bruce Momjian
Subject Re: Planning incompatibilities for Postgres 10.0
Date
Msg-id 20130527120746.GA23164@momjian.us
Whole thread Raw
In response to Re: Planning incompatibilities for Postgres 10.0  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Planning incompatibilities for Postgres 10.0  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Sun, May 26, 2013 at 09:18:41PM -0400, Stephen Frost wrote:
> * Josh Berkus (josh@agliodbs.com) wrote:
> > and it's entirely possible that we'll be able to implement SMs without
> > breaking pgupgrade.
> 
> I'd certainly hope so..  It's certainly not obvious, to me at least,
> why a new SM or supporting any of those features would require
> breaking pg_upgrade.  Perhaps there's something I'm not seeing there,
> but it had better be a *really* good reason..

If I had to _guess_, I would say users who are using the default storage
manager would still be able to use pg_upgrade, and those using
non-default storage managers perhaps can't.

But, again, this is all so hypothetical that it doesn't seem worth
talking about.  My big point is that someone came to me at PGCon asking
if I knew anything about why Simon thought we needed to break pg_upgrade
in <2 years, and I said no, so I had go digging into my email to find
out what was going on.  Simon has a very visible position in the
community, so when he suggests something, people take it seriously,
which means I have to address it.  I would prefer if there was more
thought put into the ideas before they are posted.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: PostgreSQL Process memory architecture
Next
From: Stephen Frost
Date:
Subject: Re: PostgreSQL Process memory architecture