From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: In-Place upgrade concept |
Date: | 2007-07-03 22:17:38 |
Message-ID: | 87ved1169p.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2007-07-03 22:22:26 | Re: Still recommending daily vacuum... |
Previous Message | Kevin Grittner | 2007-07-03 22:17:22 | Re: Still recommending daily vacuum... |