Re: Big 7.1 open items

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, 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>
Subject: Re: Big 7.1 open items
Date: 2000-06-21 15:45:12
Message-ID: 200006211545.LAA08773@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Yes, agreed. I was thinking this:
> > CREATE TABLESPACE loc USING '/var/pgsql'
> > does:
> > ln -s /var/pgsql/dbname/loc data/base/dbname/loc
> > In this way, the database has a view of its main directory, plus a /loc
> > subdirectory for the tablespace. In the other location, we have
> > /var/pgsql/dbname/loc because this allows different databases to use:
> > CREATE TABLESPACE loc USING '/var/pgsql'
> > and they do not collide with each other in /var/pgsql.
>
> But they don't collide anyway, because the dbname is already unique.
> Isn't the extra subdirectory a waste?

Not really. Yes, we could put them all in the same directory, but why
bother. Probably easier to put them in unique directories per database.
Cuts down on directory searches to open file, and allows 'du' to return
meaningful numbers per database. If you don't do that, you can't really
tell what files belong to which databases.

>
> Because table files will have installation-wide unique names, there's
> no really good reason to have either level of subdirectory; you could
> just make
> CREATE TABLESPACE loc USING '/var/pgsql'
> do
> ln -s /var/pgsql data/base/dbname/loc
> and it'd still work even if multiple DBs were using the same tablespace.
>
> However, forcing creation of a subdirectory does give you the chance to
> make sure the subdir is owned by postgres and has the right permissions,
> so there's something to be said for that. It might be reasonable to do
> mkdir /var/pgsql/dbname
> chmod 700 /var/pgsql/dbname
> ln -s /var/pgsql/dbname data/base/dbname/loc

Yes, that is true. My idea is that they may want to create loc1 and
loc2 which initially point to the same location, but later may be moved.
For example, one tablespace for tables, another for indexes. They may
initially point to the same directory, but later be split. Seems we
need to keep the actual tablespace information relivant by using
different directories on the other end too.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-06-21 15:46:01 Re: AW: Big 7.1 open items
Previous Message Bruce Momjian 2000-06-21 15:39:23 Re: Big 7.1 open items]

Browse pgsql-patches by date

  From Date Subject
Next Message Lamar Owen 2000-06-21 15:48:19 Re: Big 7.1 open items
Previous Message Tom Lane 2000-06-21 15:28:09 Re: Big 7.1 open items