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

WIP: pre-upgrade page reservation

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: WIP: pre-upgrade page reservation
Date: 2008-12-16 21:38:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I attached contrib module which is base of preupgrade script. It should be part 
of 8.4, but it will be required for 8.4->8.5 upgrade.

This part contains space reservation for heap/toast relations. The idea is that 
relation is read and each block is checked if there is enough free space. Tuples 
which will not be visible after upgrade are not count. If there is no space, 
then simple_heap_update on tuple(s) until we release enough space.

BTree space reservation is more complicated. I plan to use _bt_split and split 
page to two half pages with following code:

firstright = _bt_findsplitloc(rel, page, InvalidOffsetNumber, 0,&newitemonleft);
  _bt_split(rel, buffer, firstright, InvalidOffsetNumber, 0, NULL,newitemonleft);
_bt_insert_parent(rel, buffer, rbuffer, stack, is_root, is_only);

Because both functions (_bt_findsplintloc, _bt_split) expect that we want to 
insert new item, It will requires modification to accept InvalidOffsetNumber.

Another problem is to build stack which require to use deep tree scan. I hope 
that it will not require exclusive lock on index.

I'm not yet look on hash, gist and gin. I think that hash index should be easy, 
because index tuples can be moved into new bucket page. (Note: general problem 
with hash index is still bitmap pages).

I guess solution for Gist index should be similar to BTree, but I don't have any 
  idea about GIN.

	Comments, ideas, better solutions?

		thanks Zdenek

PS: This patch requires previous patch which implemented space reservation 

Attachment: preupgrade.patch
Description: text/x-diff (8.7 KB)


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-12-16 21:43:27
Subject: Re: Elide null updates
Previous:From: Tom LaneDate: 2008-12-16 21:36:35
Subject: Re: Another issue in default-values patch: defaults expanded too soon

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