Re: Proposal: In-Place upgrade concept - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Proposal: In-Place upgrade concept
Date
Msg-id 87ved1169p.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Proposal: In-Place upgrade concept  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: In-Place upgrade concept  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> 2. Page format conversion is WAL-logged as a complete page replacement

It seems we get that for free. By definition any modification to a page after
conversion will be the first record for that page since a checkpoint. It just
means we have to force full_page_writes to be true, at least for a buffer
that's been converted if not whenever we're processing a mixed format
database.

> On the whole I think we could define format conversions for user-defined
> types as "not our problem".  

Hm, perhaps we could do it by doing as much of the work up-front as possible.
Requiring datatypes to define a function in pg_proc to do the conversion and
require that it be a function which can stand on its own without catalog
lookups or other facilities. Then when we start up on a mixed format database
we load all those functions into a hash by typeoid and provide that hash to
bufmgr. By definition any datatypes we expect to find in the database must
already be in the catalog before we start.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Still recommending daily vacuum...
Next
From: "Kevin Grittner"
Date:
Subject: Re: Still recommending daily vacuum...