CLUSTER patch - Mailing list pgsql-patches

From Alvaro Herrera
Subject CLUSTER patch
Date
Msg-id Pine.LNX.4.44.0207140128340.11746-200000@cm-lcon1-46-187.cm.vtr.net
Whole thread Raw
Responses Re: CLUSTER patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: CLUSTER patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Hello:

I think I have some more knowledge on my failing to build a working
CLUSTER patch.  It does not help me to fix it, however.

The way the cluster is done is still the same: first cluster the heap
and swap relfilenodes, then drop old heap; then rebuild each index, swap
relfilenodes with old index and drop new.

If I don't use the new relfilenode for anything after building it,
everything works OK.  But I can't attach the old filenode to the new
heap; it has to stay around.  I do can attach the new filenode to the
old heap however.  But as soon as I try to do anything to it (the new,
clustered filenode) before transaction commit (building an index, say),
the local buffer manager fails an assertion (actually,
RelationNodeCacheGetRelation returns 0 for the given rnode), and the
transaction aborts.

Thus, if I comment the lines that attach the old rnode to the new heap
and the lines that create the new indexes, the cluster works, and I now
have two tables with the same rnode, one of the named
"temp_<oid-of-the-other>".  Obviously dropping any of those renders the
other useless (no disk storage).


What I still don't understand is why the RelationNodeCache doesn't
return the buffer I'm looking for.  I added some debugging fprintf's to
the bufmgr code and the relation _is_ entered (!?) during the cluster
transaction.  Maybe somewhere the local buffer manager drops the
knowledge about the relation, or that knowledge is based on (OID +
rnode) info, which changed because the rnode changed.  I do not
understand the relcaching bussiness anyway.


I attach anyway the old version of the patch, that reconstructs the
indexes without the filenode swapping bussiness.  The observations done
to the earlier patch are corrected.  I think that if nothing comes to
fix the problems with the newer approach and there are no other
objections, this one should be applied as it enhances the current
version anyway.

I'm leaving for winter vacation on monday and probably won't be back on
two weeks.

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"La vida es para el que se aventura"

Attachment

pgsql-patches by date:

Previous
From: Brent Verner
Date:
Subject: Re: COPY with column list
Next
From: Bruce Momjian
Date:
Subject: Re: CLUSTER patch