Re: 9.5 release notes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: 9.5 release notes
Date
Msg-id 20150611145417.GC19472@momjian.us
Whole thread Raw
In response to Re: 9.5 release notes  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: 9.5 release notes  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Jun 11, 2015 at 10:20:13AM +0530, Amit Kapila wrote:
> On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian <bruce@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 <robertmhaas@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  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: DBT-3 with SF=20 got failed
Next
From: Andres Freund
Date:
Subject: Re: Entities created in one query not available in another in extended protocol