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

Re: Big 7.1 open items

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Subject: Re: Big 7.1 open items
Date: 2000-06-27 23:16:27
Message-ID: 395935CB.2CC10452@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Yes, good point about pg_shadow.  They don't have databases.  How do we
> > get multiple pg_class tables in the same directory?  Is the
> > pg_class.relversion file a number like 1,2,3,4, or does it come out of
> > some global counter like oid.  If so, we could put them in the same
> > directory.
>
> I think we could get away with insisting that each database store its
> pg_class and friends in a separate tablespace (physically distinct
> directory) from any other database.  That gets around the OID conflict.
>
> It's still an open question whether OID+version is better than
> unique-ID for naming files that belong to different versions of the
> same relation.  I can see arguments on both sides.
>

I don't stick to unique-ID. My main point has always been the
transactional control of file allocation change.
However *VERSION(_ID)* may be misleading because it couldn't
mean the version of pg_class tuples.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp



In response to

pgsql-hackers by date

Next:From: The Hermit HackerDate: 2000-06-28 01:18:54
Subject: Re: Mailing List Archive Problem?
Previous:From: Giles LeanDate: 2000-06-27 22:48:52
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump

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