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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: hlinnaka <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file
Date: 2015-05-13 20:40:21
Message-ID: 5553B6B5.6040804@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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(at)dunslane(dot)net
> <mailto:andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2015-05-13 22:48:12 pgsql: Fix distclean/maintainer-clean targets to remove top-level tmp_i
Previous Message Robert Haas 2015-05-13 19:28:07 pgsql: Fix comment.

Browse pgsql-hackers by date

  From Date Subject
Next Message Aaron W. Swenson 2015-05-13 20:47:58 Fix token exceeding NAMELEN
Previous Message Alvaro Herrera 2015-05-13 20:05:54 Re: Proposal : REINDEX xxx VERBOSE