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: