Re: pg_migrator issues

On Mon, Jan 4, 2010 at 3:33 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > Robert Haas wrote:
>> >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> >> > Alvaro Herrera wrote:
>> >> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails
>> >> >> > if the tablespaces are on mount points. ?I have already received a
>> >> >> > report of such a failure.
>> >> >>
>> >> >> I thought it was impossible to use bare mountpoints as tablespaces due
>> >> >> to ownership problems ... Is that not the case? ?-1 for special hacks
>> >> >> that work around bogus setups, if that means intrusive changes to the
>> >> >> core code.
>> >> >
>> >> > I talked to the person who reported the problem and he and I confirmed
>> >> > that it is quite easy to make the mount point be owned by the postgres
>> >> > user and have that function as a tablespace. ?Is that not a supported
>> >> > setup? ?There is probably a larger problem that the tablespace must be
>> >> > located in a directory that has directory rename permission for
>> >> > postgres. ?I have updated the pg_migrator INSTALL file to mention this
>> >> > issue.
>> >> >
>> >> > As far as .old, we could create the tablespaces as *.new, but that kind
>> >> > of defeats the existing recommended pg_migrator usage where we tell the
>> >> > user to rename PGDATA to .old before running pg_migrator.
>> >> >
>> >> > It was actually Tom's idea months ago to put a version-specific
>> >> > directory in the tablespace. ?I don't think it is necessary, and we can
>> >> > live with the mount point limitation.
>> >>
>> >> 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.?

...Robert