On Thu, 4 Dec 2008, Zdenek Kotala wrote:
1) Keep relfileid of toast file same. It is important because toast pointer
contains relfileid. Currently script creates fake files with same number to
protect postgresql to create new relation with this refileid. It works but by
my opinion it is not much robust. I suggest to use following syntax:
create table foo (id int) with (relfileid=16544, reltoastid=11655,
reltoastidx=16543)
But once there's a more core integrated in-place upgrade, as envisioned
for 8.4->8,5, this syntax wouldn't been useful for anything anymore,
right? I understand your distaste for the hack, but it seems a bit
extreme to start fiddling with CREATE TABLE and pg_dump* just to implement
a work-around for a temporary problem. I think your magic is strong
enough for this, as long as the upgrade script does some sanity checks and
proceeds cautiously I think we can live with it.
Another problem with tablespace location is that CREATE TABLESPACE
checks if directory is empty and it fails when it contains any
file/directory...Suggested sugar syntax is:
CREATE DATABASE foobar WITH ID=17012;
CREATE TABLESPACE bar LOCATION '/dev/null/' ID=15543 IGNORECONTENT;
The logic of the above continues here; the "id=xxx" construct seems like
it will be useless clutter in the future, and if the script is capable of
sorting it out with a bit of hacking then go with that. The way I see
things, the sequence of events will go like this:
-Create new cluster
-Restore schema
-Fiddle with IDs, table spaces, etc.
-Then, only if there were no errors or problems with the above, are the
old files moved over.
As long as all the hacking and safety checks happen before any of the
original files are touched at all, it's kind of ugly but it should work
well enough for the target audience: relatively saavy DBAs who just can't
take the time for a dump/reload because their database is too large. The
kind of admins who doesn't know how to test and stage a major version
upgrade with appropriate backups are the group that are still running
PG7.4.[1]
I'm not sure if the same logic applies to the "IGNORECONTENT" suggestion
for tablespaces though. I know I've been vaguely annoyed by that
limitation before, typically because it would have been easier to directly
use a new mount point as a tablespace except that there's a "lost+found"
directory in there. End up adding another directory level for no good
reason. This seems like a relatively small caliber foot-gun to provide;
will have to take a look at the code to see if I still feel that way
afterwards, if nobody jumps up to protest the whole concept first that is.
[1] I hereby propose Greg's Law of DBAs: the larger and more critical a
database is, the more likely it is to attract a clueful DBA to take care
of it.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
