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
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. |
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 |