On Thu, Jun 11, 2015 at 10:20:13AM +0530, Amit Kapila wrote:
> On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian <br...@momjian.us> wrote:
> >
> > I have committed the first draft of the 9.5 release notes. You can view
> > the output here:
> >
> > http://momjian.us/pgsql_docs/release-9-5.html
> >
>
> Thanks for writing the Release notes.
>
> Some comments:
>
> Have pg_basebackup use a tablespace mapping file, to allow for file paths of
> 100+ characters in length
>
> I think this is not completely correct. This is mainly done to allow
> usage of tar format in Windows when tablespaces are present
> in database, although we have eventually done it for both
> Windows and Linux in the same way. So how about:
>
> Have pg_basebackup use a tablespace mapping file, to allow usage of tar format
> consistently across all platforms
Actually, the file fixes 100+ char on all platforms _and_ Windows symbolic
links:
Map basebackup tablespaces using a tablespace_map file
Windows can't reliably restore symbolic links from a tar format, so
instead during backup start we create a tablespace_map file, which
is
used by the restoring postgres to create the correct links in
pg_tblspc.
The backup protocol also now has an option to request this file to
be
included in the backup stream, and this is used by pg_basebackup
when
operating in tar mode.
This is done on all platforms, not just Windows.
This means that pg_basebackup will not not work in tar mode against
9.4
and older servers, as this protocol option isn't implemented there.
Amit Kapila, reviewed by Dilip Kumar, with a little editing from me.
(Andrew Dunstan)
[72d422a52] 2015-05-12 09:29:10 -0400
pg_basebackup -F t now succeeds with a long symlink target
Error when creating names too long for tar format
The tar format (at least the version we are using), does not support
file names or symlink targets longer than 99 bytes. Until now, the
tar
creation code would silently truncate any names that are too long.
(Its
original application was pg_dump, where this never happens.) This
creates problems when running base backups over the replication
protocol.
The most important problem is when a tablespace path is longer than
99
bytes, which will result in a truncated tablespace path being
backed up.
Less importantly, the basebackup protocol also promises to back up
any
other files it happens to find in the data directory, which would
also
lead to file name truncation if someone put a file with a long name
in
there.
Now both of these cases result in an error during the backup.
Add tests that fail when a too-long file name or symlink is
attempted to
be backed up.
Reviewed-by: Robert Hass <robertmh...@gmail.com>
(Peter Eisentraut)
[23a78352c] 2015-02-24 13:41:07 -0500
>
> Also shall we mention about below in Migrations to 9.5 section
>
> "pg_basebackup will not not work in tar mode against 9.4 and older servers,
> as we have introduced a new protocol option in that mode."
Yes, added. The attached, applied patch has both of these mentions, and
mentions 'tar' mode.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml
new file mode 100644
index 2073f74..f022050
*** a/doc/src/sgml/release-9.5.sgml
--- b/doc/src/sgml/release-9.5.sgml
***************
*** 1322,1329 ****
<listitem>
<para>
! Have <application>pg_basebackup</> use a tablespace mapping file,
! to allow for file paths of 100+ characters in length (Amit Kapila)
</para>
</listitem>
--- 1322,1336 ----
<listitem>
<para>
! Have <application>pg_basebackup</> use a tablespace mapping
! file with the <application>tar</> format, to handle file paths
! of 100+ characters in length and sybolic links on <systemitem
! class="osname">MS Windows</> (Amit Kapila)
! </para>
!
! <para>
! This change prevents <application>pg_basebackup</> from backing
! up pre-9.5 servers.
</para>
</listitem>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
