On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian <bruce@momjian.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...
...Robert
