From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)atentus(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] CLUSTER not lose indexes |
Date: | 2002-07-15 22:54:09 |
Message-ID: | Pine.LNX.4.44.0207130051430.28230-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane writes:
> > Also, is the new relfilenode somehow guaranteed to
> > not be assigned to another relation (pg_class tuple, I think)?
>
> I've been wondering about that myself. We might have to add a unique
> index on pg_class.relfilenode to ensure this; otherwise, after OID
> wraparound there would be no guarantees.
I've never been happy with the current setup. It's much too tempting to
think file name = OID, both in the backend code and by external onlookers,
especially since it's currently rare/impossible(?) for them to be
different.
It would be a lot clearer if relfilenode were replaced by an integer
version, starting at 0, and the heap files were named "OID_VERSION".
(In related news, how about filling up the oid/relfilenode numbers with
zeros on the left, so a directory listing would reflect the numerical
order?)
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-07-15 22:54:42 | Future of src/utils |
Previous Message | Peter Eisentraut | 2002-07-15 22:53:36 | Unused system table columns |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-07-15 22:58:41 | Re: [PATCHES] CLUSTER not lose indexes |
Previous Message | Bruce Momjian | 2002-07-15 21:31:00 | utils C files |