Skip site navigation (1) Skip section navigation (2)

Re: Big 7.1 open items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, "Thomas Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
Subject: Re: Big 7.1 open items
Date: 2000-06-22 03:27:10
Message-ID: 7153.961644430@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> Please add my opinion to the list.
> Unique-id filename: Hiroshi
>  (Unqiue-id is irrelevant to OID/relname).

"Unique ID" is more or less equivalent to "OID + version number",
right?

I was trying earlier to convince myself that a single unique-ID value
would be better than OID+version for the smgr interface, because it'd
certainly be easier to pass around.  I failed to convince myself though,
and the thing that bothered me was this.  Suppose you are trying to
recover a corrupted database manually, and the only information you have
about which table is which is a somewhat out-of-date listing of OIDs
versus table names.  (Maybe it's out of date because you got it from
your last backup tape.)  If the files are named OID+version you're not
going to have much trouble seeing which is which, even if some of the
versions are higher than what was on the tape.  But if version-updated
tables are given entirely new unique IDs, you've got no hope at all of
telling which one corresponds to what you had in the listing.  Maybe
you can tell by looking through the physical file contents, but
certainly this way is more fragile from the point of view of data
recovery.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-06-22 03:32:19
Subject: Memory management revisions, take 2
Previous:From: Tom LaneDate: 2000-06-22 03:18:19
Subject: Re: An idea on faster CHAR field indexing

pgsql-patches by date

Next:From: Chris BitmeadDate: 2000-06-22 03:43:56
Subject: Re: Big 7.1 open items
Previous:From: Bruce MomjianDate: 2000-06-22 02:29:42
Subject: Re: Big 7.1 open items

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group