Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file
От | Andrew Dunstan |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file |
Дата | |
Msg-id | 5554D470.1080107@dunslane.net обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces
using a tablespace_map file
Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file |
Список | pgsql-hackers |
On 05/14/2015 10:52 AM, Robert Haas wrote: > On Thu, May 14, 2015 at 12:12 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan <andrew@dunslane.net> wrote: >>> How about if we simply abort if we find a non-symlink where we want the >>> symlink to be, and only remove something that is actually a symlink (or a >>> junction point, which is more or less the same thing)? >> We can do that way and for that I think we need to use rmdir >> instead of rmtree in the code being discussed (recovery path), >> OTOH we should try to minimize the errors raised during >> recovery. > I'm not sure I understand this issue in detail, but why would using > rmtree() on something you expect to be a symlink ever be a good idea? > It seems like if things are the way you expect them to be, it has no > benefit, but if they are different from what you expect, you might > blow away a ton of important data. > > Maybe I am just confused. > The suggestion is to get rid of using rmtree. Instead, if we find a non-symlink in pg_tblspc we'll make the user clean it up before we can continue. So your instinct is in tune with my suggestion. cheers andrew
В списке pgsql-hackers по дате отправления: