Re: Alpha releases: How to tag - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Alpha releases: How to tag
Date
Msg-id 672.1249682552@sss.pgh.pa.us
Whole thread Raw
In response to Re: Alpha releases: How to tag  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Alpha releases: How to tag  (David Fetter <david@fetter.org>)
Re: Alpha releases: How to tag  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: contrib/pg_freespacemap
Next
From: Tom Lane
Date:
Subject: Re: contrib/pg_freespacemap