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Ü -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
