Prevent buffer overrun in read_tablespace_map().

Robert Foggia of Trustwave reported that read_tablespace_map()
fails to prevent an overrun of its on-stack input buffer.
Since the tablespace map file is presumed trustworthy, this does
not seem like an interesting security vulnerability, but still
we should fix it just in the name of robustness.

While here, document that pg_basebackup's --tablespace-mapping option
doesn't work with tar-format output, because it doesn't.  To make it
work, we'd have to modify the tablespace_map file within the tarball
sent by the server, which might be possible but I'm not volunteering.
(Less-painful solutions would require changing the basebackup protocol
so that the source server could adjust the map.  That's not very
appetizing either.)

doc/src/sgml/ref/pg_basebackup.sgml

@@ -161,6 +161,7 @@ PostgreSQL documentation
             tablespaces, the main data directory will be placed in the
             target directory, but all other tablespaces will be placed
             in the same absolute path as they have on the source server.
+            (See <option>--tablespace-mapping</option> to change that.)
            </para>
            <para>
             This is the default format.
@@ -241,7 +242,12 @@ PostgreSQL documentation
         the main data directory are updated to point to the new location.  So
         the new data directory is ready to be used for a new server instance
         with all tablespaces in the updated locations.
-        </para>
+       </para>
+
+       <para>
+        Currently, this option only works with plain output format; it is
+        ignored if tar format is selected.
+       </para>
       </listitem>
      </varlistentry>
 

src/backend/access/transam/xlog.c

@@ -11718,7 +11718,7 @@ read_tablespace_map(List **tablespaces)
 		}
 		else if ((ch == '\n' || ch == '\r') && prev_ch == '\\')
 			str[i - 1] = ch;
-		else
+		else if (i < sizeof(str) - 1)
 			str[i++] = ch;
 		prev_ch = ch;
 	}