Re: pg_basebackup vs. Windows and tablespaces

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dilip kumar <dilip(dot)kumar(at)huawei(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup vs. Windows and tablespaces
Date: 2014-12-15 00:19:38
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 12/14/2014 07:09 PM, Tom Lane wrote:
> 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.

Using an escaping convention makes by far the most sense to me. It's
what occurred to me earlier today even before I read the above. We could
adopt the URL convention of %xx for escapable characters - that would
avoid \ nastiness.



In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2014-12-15 00:43:40 DROP PRIVILEGES OWNED BY
Previous Message Michael Paquier 2014-12-15 00:09:06 Re: Custom timestamp format in logs