Skip site navigation (1) Skip section navigation (2)

Re: [WIP] In-place upgrade

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] In-place upgrade
Date: 2008-11-04 01:27:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
> Really, what I'd ideally like to see here is a system where the V3
> code is in essence error-recovery code.  Everything should be V4-only
> unless you detect a V3 page, and then you error out (if in-place
> upgrade is not enabled) or jump to the appropriate V3-aware code (if
> in-place upgrade is enabled).  In theory, with a system like this, it
> seems like the overhead for V4 ought to be no more than the cost of
> checking the page version on each page read, which is a cheap sanity
> check we'd be willing to pay for anyway, and trivial in cost.

We already do check the page version on read-in --- see PageHeaderIsValid.

> But I think we probably need some input from -core on this topic as well.

I concur that I don't want to see this patch adding more than the
absolute unavoidable minimum of overhead for data that meets the
"current" layout definition.  I'm disturbed by the proposal to stick
overhead into tuple header access, for example.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: ITAGAKI TakahiroDate: 2008-11-04 01:41:09
Subject: Re: [PATCHES] Solve a problem of LC_TIME of windows.
Previous:From: Robert HaasDate: 2008-11-04 01:20:31
Subject: Re: [WIP] In-place upgrade

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group