Re: [HACKERS] CLUSTER TODO item
Bruce Momjian <[EMAIL PROTECTED]> writes: > Can I get a status on this? It's not gonna happen for 7.2, I think ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CLUSTER TODO item
Can I get a status on this? > On Sun, 23 Sep 2001, Tom Lane wrote: > > > > Note: I'm not convinced that relfilenode and pg_class.oid are each > > used in exactly the right spots. Once we have cases where they can > > differ, we may well find some bugs to flush out. But that needs to > > happen anyway, so don't let it dissuade you from doing CLUSTER the > > right way. > > I think I may have broken stuff. I'm not sure. I've fiddled a fair bit but > I'm still segfaulting in the storage manager. It might be because I'm > heap_creating and then just stealing relfilenode - I don't know. > > Anyway, a patch is attached which clusters and then recreates the indexes > - but then segfaults. > > Am I going about this all wrong? > > Thanks > > Gavin Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CLUSTER TODO item
On Sun, 23 Sep 2001, Tom Lane wrote:
>
> Note: I'm not convinced that relfilenode and pg_class.oid are each
> used in exactly the right spots. Once we have cases where they can
> differ, we may well find some bugs to flush out. But that needs to
> happen anyway, so don't let it dissuade you from doing CLUSTER the
> right way.
I think I may have broken stuff. I'm not sure. I've fiddled a fair bit but
I'm still segfaulting in the storage manager. It might be because I'm
heap_creating and then just stealing relfilenode - I don't know.
Anyway, a patch is attached which clusters and then recreates the indexes
- but then segfaults.
Am I going about this all wrong?
Thanks
Gavin
*** src/backend/commands/cluster.c Mon Sep 24 16:01:31 2001
--- src/backend/commands/cluster.c.orig Sun Sep 23 16:37:35 2001
***
*** 24,33
#include "access/genam.h"
#include "access/heapam.h"
- #include "catalog/catname.h"
#include "catalog/heap.h"
#include "catalog/index.h"
- #include "catalog/indexing.h"
#include "catalog/pg_index.h"
#include "catalog/pg_proc.h"
#include "commands/cluster.h"
--- 24,31
***
*** 37,46
#include "utils/builtins.h"
#include "utils/syscache.h"
#include "utils/temprel.h"
! #include "utils/relcache.h" // for RelationGetIndexList()
static Oidcopy_heap(Oid OIDOldHeap, char *NewName, bool istemp);
! static void new_index(Oid OIDOldIndex, Oid OIDHeap, char *NewIndexName);
static void rebuildheap(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex);
/*
--- 35,44
#include "utils/builtins.h"
#include "utils/syscache.h"
#include "utils/temprel.h"
!
static Oidcopy_heap(Oid OIDOldHeap, char *NewName, bool istemp);
! static void copy_index(Oid OIDOldIndex, Oid OIDNewHeap, char *NewIndexName);
static void rebuildheap(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex);
/*
***
*** 62,93
OIDOldIndex,
OIDNewHeap;
RelationOldHeap,
! OldIndex,
! NewHeap,
! relrelation;
HeapTuple tuple;
- TupleDesc tupdesc;
-
boolistemp;
charNewHeapName[NAMEDATALEN];
charNewIndexName[NAMEDATALEN];
charsaveoldrelname[NAMEDATALEN];
charsaveoldindexname[NAMEDATALEN];
- List*OldIndexOids;
-
- Relationirelations[Num_pg_class_indices];
-
- /* put the details of index name/oid of the OldHeap
-* in here to speed things up and make it all cleaner
-*/
-
- struct OldIndexData {
- char oldindname[NAMEDATALEN];
- char newindname[NAMEDATALEN];
- };
-
- List *OldIndices = NULL;
- List *ltmp;
/*
* Copy the arguments into local storage, just to be safe.
--- 60,72
OIDOldIndex,
OIDNewHeap;
RelationOldHeap,
! OldIndex;
HeapTuple tuple;
boolistemp;
charNewHeapName[NAMEDATALEN];
charNewIndexName[NAMEDATALEN];
charsaveoldrelname[NAMEDATALEN];
charsaveoldindexname[NAMEDATALEN];
/*
* Copy the arguments into local storage, just to be safe.
***
*** 100,109
* duration of the transaction.
*/
OldHeap = heap_openr(saveoldrelname, AccessExclusiveLock);
-
- /* Preserve all indices. - gavin */
- OldIndexOids = RelationGetIndexList(OldHeap);
-
OIDOldHeap = RelationGetRelid(OldHeap);
OldIndex = index_openr(saveoldindexname);
--- 79,84
***
*** 135,213
*/
snprintf(NewHeapName, NAMEDATALEN, "temp_%u", OIDOldHeap);
/*
!* heap_create needs this. Unsure if I can just give it a
!* zero'd structure. Lets use the current one instead
*/
! tupdesc = CreateTupleDescCopyConstr(RelationGetDescr(OldHeap));
-
- NewHeap = heap_create(NewHeapName,tupdesc,istemp,true,
- allowSystemTableMods);
-
- /* Is this required here ? */
CommandCounterIncrement();
! OIDNewHeap = RelationGetRelid(NewHeap);
/*
!* Copy the heap data into the new table in the desired order.
*/
! rebuildheap(OIDNewHeap, OIDOldHeap, OIDOldIndex);
! heap_close(NewHeap,NoLock);
! /* To make the new heap's data visible. */
CommandCounterIncrement();
! /
Re: [HACKERS] CLUSTER TODO item
>> I've been looking at CLUSTER today. I've put together a patch which >> recreates all the indices which current CLUSTER drops and copies relacl >> from the old pg_class tuple and puts it in the new one. This is entirely the wrong way to go at it. > We did strange things with this in the past because we didn't have > pg_class.relfilenode. Now that we do, you can just recreate the heap > table using a different oid filename and update relfilenode when you are > done. Yes. CLUSTER should not do one single thing to the system catalogs, except heap_update the pg_class rows for the table and indexes with new relfilenode values. That is the facility that a rewrite of CLUSTER was waiting for, so now that we have it, it's pointless to put more work into the old CLUSTER implementation. Note: I'm not convinced that relfilenode and pg_class.oid are each used in exactly the right spots. Once we have cases where they can differ, we may well find some bugs to flush out. But that needs to happen anyway, so don't let it dissuade you from doing CLUSTER the right way. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CLUSTER TODO item
> Hi guys, > > I've been looking at CLUSTER today. I've put together a patch which > recreates all the indices which current CLUSTER drops and copies relacl > from the old pg_class tuple and puts it in the new one. > > I was working on updating pg_inherits to handle the new OID when it > occured to me that pg_inherits is not the only system table > corrupted. pg_trigger, pg_rewrite (and therefore views) and pg_description > need to be updated as well. It seems like the easiest thing to do would be > to update the new relation to have to OID of the old relation. Is there > any reason why we would not want to do this? We did strange things with this in the past because we didn't have pg_class.relfilenode. Now that we do, you can just recreate the heap table using a different oid filename and update relfilenode when you are done. Keep the same oid. Of course, as you noted, the old indexes have to be recreated because the heap has changed. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
