Re: Planning incompatibilities for Postgres 10.0

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Planning incompatibilities for Postgres 10.0
Date: 2013-05-27 12:07:46
Message-ID: 20130527120746.GA23164@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, May 26, 2013 at 09:18:41PM -0400, Stephen Frost wrote:
> * Josh Berkus (josh(at)agliodbs(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-05-27 12:09:03 Re: PostgreSQL Process memory architecture
Previous Message Atri Sharma 2013-05-27 11:55:48 Re: PostgreSQL Process memory architecture