From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Tablespaces |
Date: | 2004-03-03 16:35:40 |
Message-ID: | 874qt5c2hv.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-hackers-win32 |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Greg Stark wrote:
> >
> > > > I am expecting to hear some bleating about this from people whose
> > > > preferred platforms don't support symlinks ;-). However, if we don't
> >
> > Well, one option would be to have the low level filesystem storage (md.c?)
> > routines implement a kind of symlink themselves. Just a file with a special
> > magic number followed by a path.
On further contemplation it doesn't seem like using symlinks really ought to
be necessary. It should be possible to drive everything off the catalog tables
while avoidin having the low level filesystem code know anything about them.
Instead of having the low level code fetch the pg_* records themselves, some
piece of higher level code would do the query and call down to storage layer
to inform it of the locations for everything. It would have to do this on
database initialization and on any subsequent object creation.
Basically maintain an in-memory hash table of oid -> path, and call down to
the low level code whenever that hash changes. (Or more likely oid->ts_id and
a separate list of ts_id -> path.)
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Barry Lind | 2004-03-03 17:05:41 | Re: Tablespaces |
Previous Message | Tom Lane | 2004-03-03 16:14:54 | Re: Client side copy functionality |
From | Date | Subject | |
---|---|---|---|
Next Message | Barry Lind | 2004-03-03 17:05:41 | Re: Tablespaces |
Previous Message | Magnus Hagander | 2004-03-03 15:22:30 | Re: [HACKERS] Tablespaces |