On Tue, Dec 1, 2009 at 3:04 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> I find that hard to understand. I believe the consensus is that an
> on-demand page-level migration statregy like Aidan described is
> precisely the plan when it's necessary to handle page format changes.
> There were no page format changes for 8.3->8.4 however so there's no
> point writing dead code until it actually has anything to do. And
> there was no point writing it for previously releases because there
> was pg_migrator anyways. Zdenek's plan was basically the same but he
> wanted the backend to be able to handle any version page directly
> without conversion any time.
>
> Pointing at the 8.3 pg_migrator limitations is irrelevant -- every
> single one of those limitations would not be addressed by a page-level
> migration code path. They are all data-type redefinitions that can't
> be fixed without understanding the table structure and definition.
> These limitations would all require adding code to the new version to
> handle the old data types and their behaviour and to convert them to
> the new datatypes when a tuple is rewritten. In some cases this is
> really not easy at all.

OK, fair enough.  My implication that only page formats were at issue
was off-base.  My underlying point was that I think we have to be
prepared to write code that can understand old binary formats (on the
tuple, page, or relation level) if we want this to work and work
reliably.  I believe that there has been much resistance to that idea.
 If I am wrong, great!

...Robert

In response to

• Re: Block-level CRC checks at 2009-12-01 20:04:53 from Greg Stark

Responses

• Re: Block-level CRC checks at 2009-12-01 20:41:43 from Tom Lane

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2009-12-01 20:41:43
	Subject: Re: Block-level CRC checks
Previous:	From: Tom Lane	Date: 2009-12-01 20:18:31
	Subject: Re: Application name patch - v4