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>, "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, "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 04:29:42
Message-ID: 7251.961648182@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> I strongly object to keep tablespace OID for smgr file reference token
> though we have to keep it for another purpose of cource. I've mentioned
> many times tablespace(where to store) info should be distinguished from
> *where it is stored* info.

Sure. But this proposal assumes that we're relying on symlinks to
carry the information about physical locations corresponding to
tablespace OIDs. The backend just needs to know enough to access a
relation file at a relative pathname like
tablespaceOID/relationOID
(ignoring version and segment numbers for now). Under the hood,
a symlink for tablespaceOID gets the work done.

Certainly this is not a perfect mechanism. But it is simple, it
is reliable, it is portable to most of the platforms we care about
(yeah, I know we have a Win port, but you wouldn't ever recommend
someone to run a *serious* database on it would you?), and in general
I think the bang-for-the-buck ratio is enormous. I do not want to
have to deal with explicit tablespace bookkeeping in the backend,
but that seems like what we'd have to do in order to improve on
symlinks.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Randall Parker 2000-06-22 05:11:50 Re: Big 7.1 open items
Previous Message Bruce Momjian 2000-06-22 04:03:27 Re: Big 7.1 open items

Browse pgsql-patches by date

  From Date Subject
Next Message Denis Perchine 2000-06-22 05:29:53 Re: libpq error codes
Previous Message Bruce Momjian 2000-06-22 04:03:27 Re: Big 7.1 open items