Hi,
On Tue, Jun 27, 2017 at 10:13 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Jun 27, 2017 at 12:13 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> At quick glance, I think that this should definitely be a client-only
>> fix. One reason is that pg_basebackup should be able to work with past
>> servers. A second is that this impacts as well the backend code, and
>> readlink may not return an absolute path. At least that's true for
>> posix's version, Postgres uses its own wrapper with junction points..
>
> The problem is in pg_basebackup.c's get_tablespace_mapping(), which
> fails to provide a correct comparison for the directory given by
> caller. In your case the caller of get_tablespace_mapping() uses
> backslashes as directory value (path value received from backend), and
> the tablespace mapping uses slashes as canonicalize_path has been
> called once on it. Because of this inconsistency, the directory of the
> original tablespace is used, causing the backup to fail as it should.
> A simple fix is to make sure that the comparison between both things
> is consistent by using canonicalize_path on the directory value given
> by caller.
>
> Attached is a patch. I am parking that in the next CF so as this does
> not get forgotten as a bug fix. Perhaps a committer will show up
> before. Or not.
I am still seeing the issue with the attached patch. I had a quick
look into the patch. It seems to me like you have canonicalized the
tablespace path to convert win32 slashes to unix type of slashes but
that is not being passed to strcmp() function and probably that could
be the reason why the issue is still existing. Thanks.
for (cell = tablespace_dirs.head; cell; cell = cell->next)
- if (strcmp(dir, cell->old_dir) == 0)
+ if (strcmp(canon_dir, cell->old_dir) == 0)
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
