Re: CLUSTER patch

I am working on the same thing myself. Attached is a version of the
patch that applies to current CVS. I worked with
RelationClearRelation() to clear the cache for the relations.

It now reports "Relation still open" during index_drop(), so something
still isn't right. I think the whole problem stems from the fact that
the relation cache caches by relnode, so when we change it, the cache
gets all confused. The RelationClearRelation() change handles this in a
very crude way, but it seems to be in the right direction for a
solution.

---------------------------------------------------------------------------

Alvaro Herrera wrote:
> 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"

Content-Description:

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026