Re: 9.5 release notes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.5 release notes
Date: 2015-06-11 14:54:17
Message-ID: 20150611145417.GC19472@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)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(at)gmail(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Attachment Content-Type Size
tar.diff text/x-diff 944 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-06-11 14:54:49 Re: DBT-3 with SF=20 got failed
Previous Message Kohei KaiGai 2015-06-11 14:50:43 Re: DBT-3 with SF=20 got failed