On Mon, Jan 4, 2010 at 4:53 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> >> >> What doesn't work if we just don't rename the tablespace at all? ?And
>> >> >> can't we put some smarts into the backend to handle that thing?
>> >> >
>> >> > Well, when you restore the old dump's schema into the new server, the
>> >> > tablespace directory path will be the same, so we had better not have
>> >> > any directory there.
>> >>
>> >> Well that seems like something you could work around by hacking the
>> >> contents of the dump...
>> >
>> > True, in --binary-upgrade mode, but what do we make it? ?*.new? ?What if
>> > they want to have the same tablespace names after the upgrade? ?It
>> > really gets ugly if we are on a mount point because the tablespaces will
>> > be in different file systems, which makes --link mode impossible, and
>> > might create files in a filesystem that doesn't have enough space.
>>
>> But can't we just call a special function first before running the
>> CREATE TABLESPACE, like:
>>
>> pg_tablespace_dont_really_create_this_tablespace_because_we_are_in_pg_migrator()?
>>
>> Sorta like what you did to preserve ENUM OIDs, etc.?
>
> Well, the problem is that we are creating something in a file system,
> and the old and new contents of the tablespace directories must exist
> after the migration (in case the migration is reverted). We were able
> to get away with this for enum because we were only creating this in the
> _new_ database. With the file system, we have a resource/namespace
> shared between the old and new server.
Oh, I thought you were hard-linking the files, not copying them, so
the old directory would be destroyed anyway.
> What were you thinking this function call would do?
Basically, make PostgreSQL not reinitialize the directory as it
normally would when a new tablespace is created. Or make it ignore
the existence of the directory until told to stop ignoring it. Or
whatever is needed to avoid having to move the thing around. Sorry,
I'm hand-waving wildly here; I haven't read the code. Maybe I should
shut up.
...Robert
