From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, hlinnaka <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file |
Date: | 2015-05-14 14:52:28 |
Message-ID: | CA+TgmobCLoZiPHQBSiBsp+nhZZePoib6ETvjpXM-Dabj8VHMdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Thu, May 14, 2015 at 12:12 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan <andrew(at)dunslane(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-05-14 14:57:24 | pgsql: Fix buildfarm with regard to pg_audit |
Previous Message | Stephen Frost | 2015-05-14 14:48:33 | Re: pgsql: Add pg_audit, an auditing extension |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-05-14 14:54:34 | Re: upper planner path-ification |
Previous Message | Stephen Frost | 2015-05-14 14:48:33 | Re: pgsql: Add pg_audit, an auditing extension |