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: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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 21:00:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Mikheev, Vadim writes:
>> Do we need *both* database & tablespace to find table file ?!
>> Imho, database shouldn't be used...

> Then the system tables from different databases would collide.

I've been assuming that we would create a separate tablespace for
each database, which would be the location of that database's
system tables.  It's probably also the default tablespace for user
tables created in that database, though it wouldn't have to be.

There should also be a known tablespace for the installation-wide tables
(pg_shadow et al).

With this approach tablespace+relation would indeed be a sufficient
identifier.  We could even eliminate the knowledge that certain
tables are installation-wide from the bufmgr and below (currently
that knowledge is hardwired in places that I'd rather didn't know
about it...)

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2000-06-27 21:05:49
Subject: Re: Is *that* why debugging backend startup is so hard!?
Previous:From: Stephan SzaboDate: 2000-06-27 20:10:00
Subject: Re: Proposal: More flexible backup/restore via pg_dump

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