Re: pg_basebackup fails on Windows when using tablespace mapping

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: nb <nbedxp(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup fails on Windows when using tablespace mapping
Date: 2017-06-27 04:43:46
Message-ID: CAB7nPqT9Ej0J03BGUJPKXKhnFxapts2RNe-Z4ZdE4qFrppHEyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 27, 2017 at 12:13 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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.
--
Michael

Attachment Content-Type Size
basebackup-win-tbspace.patch application/octet-stream 942 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-06-27 04:44:50 Re: Modifing returning value of PQgetvalue.
Previous Message Jeff Janes 2017-06-27 03:14:46 Re: distinct estimate of a hard-coded VALUES list