Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file - Mailing list pgsql-hackers
| From | Andrew Dunstan |
|---|---|
| Subject | Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file |
| Date | |
| Msg-id | 5553B6B5.6040804@dunslane.net Whole thread Raw |
| Responses |
Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a
tablespace_map file
|
| List | pgsql-hackers |
[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
pgsql-hackers by date: