| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, David Fetter <david(at)fetter(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Alpha releases: How to tag |
| Date: | 2009-08-09 17:16:47 |
| Message-ID: | 200908091716.n79HGlG17002@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > I think it's a lot more nebulous than that. At the same time I think the
> > days when we can blithely change the on-disk format with hardly a
> > thought for migration are over. IOW, there's agreement things have to
> > change, but the exact shape of the change is not yet clear (at least to
> > me) ;-)
>
> Yeah. I think we're going to start paying more than zero attention to
> this, but we don't yet have a handle on what the real parameters are.
> In particular, it's hard to argue that pg_migrator has yet achieved
> more than experimental status, so accepting or rejecting patches on
> the grounds of whether they would or would not break pg_migrator might
> be a bit premature. And at the other end of the spectrum, nobody except
> Zdenek wants to deal with changes as invasive as the ones he's proposed.
> So we're still feeling our way here. We do *not* have a framework in
> which someone could submit a patch that includes an on-disk migration
> aspect, so David's position that we should immediately institute a
> hard requirement for such seems a bit ivory-tower. We might as well
> just say that the on-disk format is frozen, because that's what the
> effect would be.
>
> But having said all that, I'm okay with a go-slow position on on-disk
> changes for the next little while. That would give us some breathing
> room to see if something like pg_migrator is really workable at all.
> We need to find out just how far that approach goes before we can make
> many decisions in this area.
I would be happy if we can just allow pg_migrator to _detect_
incompatible changes, and that nothing _major_ changes between releases
that pg_migrator can't fix (we fixed the sequence changes in 8.4).
/contrib changes are part of the first group, so I am happy to know
about them and detect them; changing the tuple format, on the other
hand, could make pg_migrator useless.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Boszormenyi Zoltan | 2009-08-09 17:24:37 | Re: Split-up ECPG patches |
| Previous Message | Tom Lane | 2009-08-09 17:09:42 | Re: Split-up ECPG patches |