RE: Alternative database locations are broken
От | Peter Eisentraut |
---|---|
Тема | RE: Alternative database locations are broken |
Дата | |
Msg-id | Pine.LNX.4.21.0011041414320.775-100000@peter.localdomain обсуждение исходный текст |
Ответ на | RE: Alternative database locations are broken ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Ответы |
Re: Alternative database locations are broken
|
Список | pgsql-hackers |
Mikheev, Vadim writes: > > 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 we have a bit of a problem here. In order to restore the previously existing alternative location feature we'd somehow have to stick this information into RelFileNode. Firstly, alternative locations were referenced as text strings (usually environment variable names), which doesn't seem appropriate to stick into RelFileNode. We could make a separate system catalog (as I have suggested several times) to assign oids to these locations. But RelFileNode already claims to store the identity of the table space, being the database oid. This doesn't work because a location can contain more than one database. So effectively we'd need to redefine RelFileNode something like 'struct { locationid, dbid, relid }'. I'm afraid I feel incompetent here. RelFileNode is used in too many places that I don't understand. > 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. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: