Re: pg_basebackup vs. Windows and tablespaces

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 1. The patch is completely naive about what might be in the symlink
>>> path string; eg embedded spaces in the path would break it. On at
>>> least some platforms, newlines could be in the path as well. I'm not
>>> sure about how to guard against this while maintaining human readability
>>> of the file.

> One way to deal with this could be to append a delimiter(which is not
> allowed
> in tablespace path like quote (\')) at the end of tablespace path while
> writing the same to symlink label file and then use that as end marker while
> reading it from file.

What makes you think quote isn't allowed in tablespace paths? Even if we
were to disallow it at the SQL level, there'd be nothing stopping a DBA
from changing the path after the fact by redefining the symlink outside
SQL --- something I believe we specifically meant to allow, considering
we went to the trouble of getting rid of the pg_tablespace.spclocation
column.

Pretty much the only character we can be entirely certain is not in a
symlink's value is \0. As Alvaro mentioned, using that in the file
is a possible alternative, although it could easily confuse some users
and/or text editors. The only other alternatives I can see are:

* Go over to a byte-count-then-value format. Also possible, also rather
unfriendly from a user's standpoint.

* Establish an escaping convention, eg backslash before any funny
characters. Unfortunately backslash wouldn't be too nice from the
viewpoint of Windows users.

* Make pg_basebackup check for and fail on symlinks containing characters
it can't handle. Pretty icky, though I suppose there's some argument
that things like newlines wouldn't be in any rational tablespace path.
But I doubt you can make that argument for spaces, quotes, or backslashes.

regards, tom lane