Re: pg_migrator issues

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg_migrator issues
Дата
Msg-id 603c8f071001041140ibdcf028n178eb461761aa094@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_migrator issues  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: pg_migrator issues  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
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?

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ECPG SQLDA support
Следующее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: ECPG SQLDA support