Bruce Momjian dijo:
> FYI, RENAME also deals with relfilenode renaming in setNewRelfilenode().
> The difference is that RENAME doesn't need to access the old index, just
> build a new one, so it can take shortcuts in how it handles things. It
> uses two methods to modify the tuple, one directly modifying pg_class,
> rather than inserting a new heap row. and another of doing it the
> traditional way. It does this because REINDEX is used to fix corrupt
> indexes, including corrupt system indexes. You will not be using that
> type of code in CLUSTER because there is a real temp heap associated
> with this operation. Just heap_update() like normal for both relations.
Well, I think my approach is somewhat more naive. What I'm actually
doing is something like:
1. save information on extant indexes
2. create a new heap, and populate (clustered)
3. swap the relfilenodes of the new and old heaps
4. drop new heap (with old relfilenode)
5. for each index saved in 1:
5.1. create a new index with the same attributes
5.2. swap relfilenodes of original and new index
5.3. drop new index (with old relfilenode)
But now I'm lost. It has worked sometimes; then I change a minimal
thing, recompile and then it doesn't work (bufmgr fails an assertion).
I can tell that the new (table) filenode is correct if I skip step 4
above, and check the temp table manually (but of course it has no
indexes). I've never gotten as far as completing all steps right, so I
cannot tell whether the new indexes' filenodes are correct.
I'm posting the new patch. Please review it; I've turned it upside down
a few times and frankly don't know what's happening. I sure am
forgetting a lock or something but cannot find what is it.
--
Alvaro Herrera (<alvherre[a]atentus.com>)
"Aprender sin pensar es inutil; pensar sin aprender, peligroso" (Confucio)