Re: [HACKERS] Alternative database locations are broken
Peter Eisentraut [EMAIL PROTECTED] writes: How do we control the allowed paths? Should we continue with the environment variables? Perhaps a config option listing the allowed directories? A system catalog? The environment variables are a pretty sucky mechanism, IMHO; an installation-wide catalog would be nicer. HOWEVER: I do not think it's reasonable to try to make that happen for 7.1, considering how close we are to beta. So I recommend that we continue to base allowed paths on environment variables for this release. Somehow I also get the feeling that pg_dumpall should be saving these paths... Yup, probably so. If you stick the LOCATION string into pg_database.datpath (which no longer has any other use) then it'd be easy to make pg_dumpall do so. regards, tom lane
Re: [HACKERS] Alternative database locations are broken
Okay, so we'll do the symlinks.
CREATE DATABASE xxx WITH LOCATION='/else/where';
will clone ('cp -r') template1 in /else/where/base/id and create a
symlink to there from $PGDATA/base/id. The '/else/where' location will
be stored in pg_database.datpath.
How do we control the allowed paths? Should we continue with the
environment variables? Perhaps a config option listing the allowed
directories? A system catalog?
Somehow I also get the feeling that pg_dumpall should be saving these
paths...
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Alternative database locations are broken
On Sat, Nov 04, 2000 at 10:09:16PM -0800, Vadim Mikheev wrote:
I think that to handle locations we could symlink catalogs - ln -s
path_to_database_in_some_location .../base/DatabaseOid
But that's a kludge. We ought to discourage people from messing with the
storage internals.
It's not a kluge, it's a perfectly fine implementation. The only kluge
here is if people have to reach in and establish such symlinks by hand.
We want to set up a user interface that hides the implementation.
Agreed. And I don't see problems with handling this at CREATE DATABASE
time. Create database dir in specified location, create symlink from
base dir and remember location name in pg_database.datpath.
Hmm, I know NT's not really a target, supported OS, but enshrining
symlinks in a the design of a backend feature makes it really difficult
to keep even the semblance of support. Vadim's work _finally_ stomped
the mixed case tablename bug ("Test" and "test" would collide because of
NTFSi being case insensitive). Symlinks are, I think, only supported via
a Cygwin kludge.
'Course, one could argue that running pgsql via Cygwin is all a big
kludge. I'm not even sure why I keep coming to the defense of the NT
port: I'm not using it myself. I keep getting the feeling that there's a
real opportunity there: get pgsql onto developer's NT boxes, when their
projects need a real database, rather than springing for an MS-SQL or
Oracle license. Makes moving over to a _real_ operating system (when
they start to notice those stability problems) that much easier.
But seriously, there was a long thread concerning the appropriateness
of using symlinks to manage storage, which I don't recall as coming
to a conclusion. Admittedly, the opinion of those who take the bull by
the horns and actually write the code matters more (rough concensus and
working code, as they say).
Ross
--
Open source code is like a natural resource, it's the result of providing
food and sunshine to programmers, and then staying out of their way.
[...] [It] is not going away because it has utility for both the developers
and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
Re: [HACKERS] Alternative database locations are broken
I think that to handle locations we could symlink catalogs - ln -s path_to_database_in_some_location .../base/DatabaseOid But that's a kludge. We ought to discourage people from messing with the storage internals. It's not a kluge, it's a perfectly fine implementation. The only kluge here is if people have to reach in and establish such symlinks by hand. We want to set up a user interface that hides the implementation. Agreed. And I don't see problems with handling this at CREATE DATABASE time. Create database dir in specified location, create symlink from base dir and remember location name in pg_database.datpath. Vadim
RE: [HACKERS] Alternative database locations are broken
With the new oid file naming, the alternative database location feature has disappeared. Not good. Also, is there any merit in keeping the #ifdef OLD_FILE_NAMING code path? No one. I've removed some of old code but not all, sorry. I could probably go through and fix this, but I'm not fully aware about the larger plan of table spaces that's apparently sneaking in here (cf. RelFileNode.tblNode). This would be very appreciated. Table spaces will be in 7.2, hopefully. For the moment tblNode is just database OID (InvalidOid for shared relations). I think that to handle locations we could symlink catalogs - ln -s path_to_database_in_some_location .../base/DatabaseOid TIA, Vadim
