Re: pg_basebackup fails with long tablespace paths

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: pg_basebackup fails with long tablespace paths
Дата
Msg-id CAA4eK1+AV-r7CUxY1GHm_jdjViQLfyYer5qA=dgMW4JUg0GcrA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_basebackup fails with long tablespace paths  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Wed, Jan 7, 2015 at 3:03 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>
> On 12/27/14 8:02 PM, Robert Haas wrote:
> > On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> >> On 12/22/14 10:00 PM, Amit Kapila wrote:
> >>> There is already a patch [1] in this CF which will handle both cases, so
> >>> I am
> >>> not sure if it is very good idea to go with a new tar format to handle this
> >>> issue.
> >>
> >> I think it would still make sense to have proper symlinks in the
> >> basebackup if possible, for clarity.
> >
> > I guess I would have assumed it would be more clear to omit the
> > symlinks if we're expecting the server to put them in.  Otherwise, the
> > server has to remove the existing symlinks and create new ones, which
> > introduces various possibilities for failure and confusion.
>
> Currently, when you unpack a tarred basebackup with tablespaces, the
> symlinks will tell you whether you have unpacked the tablespace tars at
> the right place.  Otherwise, how do you know?

via some kind of tablespace map file which will tell us the exact
location where symlink need to be pointed and the same will be used
to create a symlink.  So after you unpack a tarred basebackup with
tablespaces, there will be no symlinks; when you start the server
(archive recovery) using base backup, it will create the appropriate
symlinks. 

> Secondly, you also have
> the option of putting the tablespaces somewhere else by changing the
> symlinks.  Under the new scheme, the existing symlinks would be
> overwritten (or not?).  If that is actually correct, then the proposed
> fix doesn't really replicate the required functionality on Windows.
>
> One way to address this would be to do away with the symlinks altogether
> and have pg_tblspc/12345 be a text file that contains the tablespace
> location.  Kind of symlinks implemented in user space.
>

I think this is somewhat similar to what existing patch [1] does with
the different that there is just one file for all the tablespace locations
rather than individual file in each tablespace directory.
 

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [REVIEW] Re: Compression of full-page-writes