CLUSTER patch
От | Alvaro Herrera |
---|---|
Тема | CLUSTER patch |
Дата | |
Msg-id | Pine.LNX.4.44.0207140128340.11746-200000@cm-lcon1-46-187.cm.vtr.net обсуждение исходный текст |
Ответы |
Re: CLUSTER patch
Re: CLUSTER patch |
Список | 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"
Вложения
В списке pgsql-patches по дате отправления: