Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On 05/23/2015 01:29 AM, Amit Kapila wrote:
> On Fri, May 15, 2015 at 11:51 AM, Amit Kapila <amit.kapila16@gmail.com 
> <mailto:amit.kapila16@gmail.com>> wrote:
> >
> > On Thu, May 14, 2015 at 10:29 PM, Andrew Dunstan 
> <andrew@dunslane.net <mailto:andrew@dunslane.net>> wrote:
> > >
> > >
> > > 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 <mailto:amit.kapila16@gmail.com>> wrote:
> > >>>
> > >>> On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan 
> <andrew@dunslane.net <mailto: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.
> > >
> >
> > Find the patch which gets rid of rmtree usage.  I have made it as
> > a separate function because the same code is used from
> > create_tablespace_directories() as well.  I thought of extending the
> > same API for using it from destroy_tablespace_directories() as well,
> > but due to special handling (especially for ENOENT) in that function,
> > I left it as of now.
> >
>
> Does it make sense to track this in 9.5 Open Items [1]?
>
>
> [1] - https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
>
>


Sure. It's on my list of things to get to, but by all means put it there.

cheers

andrew