Re: Planning incompatibilities for Postgres 10.0

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Planning incompatibilities for Postgres 10.0
Дата
Msg-id 20130527120746.GA23164@momjian.us
обсуждение исходный текст
Ответ на Re: Planning incompatibilities for Postgres 10.0  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Planning incompatibilities for Postgres 10.0
Список 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 по дате отправления:

Предыдущее
От: Atri Sharma
Дата:
Сообщение: Re: PostgreSQL Process memory architecture
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: PostgreSQL Process memory architecture