Amit Kapila <amit.kapil...@gmail.com> writes:
>> On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane <t...@sss.pgh.pa.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to