Re: pg_migrator to /contrib in a later 9.0 beta - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_migrator to /contrib in a later 9.0 beta
Date
Msg-id 9214727845698329210@unknownmsgid
Whole thread Raw
In response to Re: pg_migrator to /contrib in a later 9.0 beta  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_migrator to /contrib in a later 9.0 beta
Re: pg_migrator to /contrib in a later 9.0 beta
List pgsql-hackers
On May 2, 2010, at 12:01 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> Andrew Dunstan wrote:
>>>> I thought the idea was just to support migration from version N to
>>>> version N+1.
>>
>>> Oh, I will also support many older _source_ versions, like 8.3 and
>>> 8.4.
>>
>> Really?  Nobody else has bought into that, and it's not only
>> pg_migrator
>> that would have to go out of its way to support such cases.  You're
>> talking about cross-multi-version compatibility of on-disk formats
>> too.
>
> Well, it works.  I have a test suite that I run regularly.  Because of
> the way pg_migrator works it is pretty painless to support multiple
> _source_ major versions.
>
> The binary format issue is relevant, but until we have a way to remove
> the old binary format, I don't see much value in supporting just one
> source version.  For example, we don't have any system now to remove
> the
> HEAP_MOVED_OFF and HEAP_MOVED_IN heap bits so effectively major
> versions
> have to support them forever.  Now, if we develop a system where a
> version would _remove_ the old data format, we would then specify that
> pg_migrator can only migrate _from_ one major version, and you would
> have to run a script to remove the old data format.  For example,
> migrating from 9.0 to 9.2 would requiring migrating from 9.0 to 9.1
> with
> pg_migrator, updating the data pages to 9.1 format, then using
> pg_migrator again to migrate from 9.1 to 9.2, but of course, we are
> not
> there yet.
>
> My guess is that when that happens we would just document/enforce it
> in
> pg_migrator, but I don't see why we would arbitrarily restrict
> pg_migrator at this time.

Yeah. It's not uncommon to want to upgrade by more than one release at
a time, and I haven't heard any reason why we should arbitrarily
refuse to support that. Of course we may need to do that eventually
for some specific reason, but it seems like we should only consider
imposing such a restriction in the face of a tangible need.

...Robert

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Show schema in COPY error CONTEXT strings
Next
From: Bruce Momjian
Date:
Subject: Re: pg_migrator to /contrib in a later 9.0 beta