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

[redirecting to -hackers]

On 05/12/2015 01:30 PM, Amit Kapila wrote:
> On Tue, May 12, 2015 at 9:02 PM, Andrew Dunstan <andrew@dunslane.net 
> <mailto:andrew@dunslane.net>> wrote:
>
>
>     On 05/12/2015 10:33 AM, Heikki Linnakangas wrote:
>
>         On 05/12/2015 04:42 PM, Andrew Dunstan wrote:
>
>             +
>             +               /*
>             +                * Remove the existing symlink if any and
>             Create the symlink
>             +                * under PGDATA.  We need to use rmtree
>             instead of rmdir as
>             +                * the link location might contain
>             directories or files
>             +                * corresponding to the actual path. Some
>             tar utilities do
>             +                * things that way while extracting symlinks.
>             +                */
>             +               if (lstat(linkloc, &st) == 0 &&
>             S_ISDIR(st.st_mode))
>             +               {
>             +                   if (!rmtree(linkloc,true))
>             +                       ereport(ERROR,
>             +  (errcode_for_file_access(),
>             +                                errmsg("could not remove
>             directory \"%s\": %m",
>             +                                       linkloc)));
>             +               }
>             +               else
>             +               {
>             +                   if (unlink(linkloc) < 0 && errno !=
>             ENOENT)
>             +                       ereport(ERROR,
>             +  (errcode_for_file_access(),
>             +                                errmsg("could not remove
>             symbolic link \"%s\": %m",
>             +                                       linkloc)));
>             +               }
>             +
>
>
>         That's scary. What tar utilitiy replaces the symlink with a
>         non-empty directory?
>
>
> IIRC, it was star utility by using --copysymlinks options.
> It will actually copy the symlink data at appropriate location,
> but will not maintain symlink after extraction.
> I don't have a link handly for it, but can again search for
> it and send you if you want to have a look.
>
>         What if you call pg_start_backup() and take the backup with a
>         utility that follows symlinks? I wouldn't recommend using such
>         a tool, but with this patch, it will zap all the tablespaces.
>         Before this, you at least got a working database and could
>         read out all the data or fix the symlinks afterwards.
>
>
>
> Yeah, but I don't think user will do such a thing without
> being aware of the same and if he is aware, he will either
> restore the symlinks before starting the server or would
> atleast keep a copy of such a backup until he is able to
> restore the database completely.
>
> Do you think adding a note in docs makes sense?



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)? Then it would 
be up to the user to recover the situation, by moving or removing the 
offending file/directory, and trying again.

cheers

andrew