On 2/2/15 8:58 AM, Robert Haas wrote:
I think we should commit this, where by this I mean your patch to
error-check the length of filenames and symlinks instead of truncating
them.
done
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 1/23/15 3:26 AM, Abhijit Menon-Sen wrote:
At 2014-12-24 08:10:46 -0500, pete...@gmx.net wrote:
As a demo for how this might look, attached is a wildly incomplete
patch to produce GNU long-link headers.
Hi Peter.
In what way exactly is this patch wildly incomplete? (I ask because it's
On Fri, Nov 7, 2014 at 9:03 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/4/14 3:52 PM, Peter Eisentraut wrote:
Here are patches to address that. First, it reports errors when
attempting to create a tar header that would truncate file or symlink
names. Second, it works around the problem
At 2014-12-24 08:10:46 -0500, pete...@gmx.net wrote:
As a demo for how this might look, attached is a wildly incomplete
patch to produce GNU long-link headers.
Hi Peter.
In what way exactly is this patch wildly incomplete? (I ask because it's
been added to the current CF).
-- Abhijit
--
On Tue, Jan 13, 2015 at 4:41 PM, Peter Eisentraut pete...@gmx.net wrote:
I think the key point I'm approaching is that the information should
only ever be in one place, all the time. This is not dissimilar from
why we took the tablespace location out of the system catalogs. Users
might have
On 1/7/15 3:19 PM, Robert Haas wrote:
On Tue, Jan 6, 2015 at 4:33 PM, Peter Eisentraut pete...@gmx.net wrote:
Currently, when you unpack a tarred basebackup with tablespaces, the
symlinks will tell you whether you have unpacked the tablespace tars at
the right place. Otherwise, how do you
On Tue, Jan 6, 2015 at 4:33 PM, Peter Eisentraut pete...@gmx.net wrote:
Currently, when you unpack a tarred basebackup with tablespaces, the
symlinks will tell you whether you have unpacked the tablespace tars at
the right place. Otherwise, how do you know? Secondly, you also have
the option
On 12/27/14 8:02 PM, Robert Haas wrote:
On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut pete...@gmx.net wrote:
On 12/22/14 10:00 PM, Amit Kapila wrote:
There is already a patch [1] in this CF which will handle both cases, so
I am
not sure if it is very good idea to go with a new tar format
On Wed, Jan 7, 2015 at 3:03 AM, Peter Eisentraut pete...@gmx.net wrote:
On 12/27/14 8:02 PM, Robert Haas wrote:
On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut pete...@gmx.net
wrote:
On 12/22/14 10:00 PM, Amit Kapila wrote:
There is already a patch [1] in this CF which will handle both
On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut pete...@gmx.net wrote:
On 12/22/14 10:00 PM, Amit Kapila wrote:
There is already a patch [1] in this CF which will handle both cases, so
I am
not sure if it is very good idea to go with a new tar format to handle this
issue.
I think it would
On 12/22/14 5:40 PM, Oskari Saarenmaa wrote:
I think we should just use the UStar tar format
(http://en.wikipedia.org/wiki/Tar_%28computing%29#UStar_format) and
allow long file names; all actively used tar implementations should be
able to handle them. I'll try to write a patch for that
On 12/22/14 10:00 PM, Amit Kapila wrote:
There is already a patch [1] in this CF which will handle both cases, so
I am
not sure if it is very good idea to go with a new tar format to handle this
issue.
I think it would still make sense to have proper symlinks in the
basebackup if possible,
23.12.2014, 05:00, Amit Kapila kirjoitti:
On Tue, Dec 23, 2014 at 4:10 AM, Oskari Saarenmaa wrote:
08.11.2014, 04:03, Peter Eisentraut kirjoitti:
It errors when the file
name is too long and adds tests for that. This could be applied to 9.5
and backpatched, if we so choose. It might
08.11.2014, 04:03, Peter Eisentraut kirjoitti:
On 11/4/14 3:52 PM, Peter Eisentraut wrote:
Here are patches to address that. First, it reports errors when
attempting to create a tar header that would truncate file or symlink
names. Second, it works around the problem in the tests by
On Tue, Dec 23, 2014 at 4:10 AM, Oskari Saarenmaa o...@ohmu.fi wrote:
08.11.2014, 04:03, Peter Eisentraut kirjoitti:
On 11/4/14 3:52 PM, Peter Eisentraut wrote:
Here are patches to address that. First, it reports errors when
attempting to create a tar header that would truncate file or
On 11/4/14 3:52 PM, Peter Eisentraut wrote:
Here are patches to address that. First, it reports errors when
attempting to create a tar header that would truncate file or symlink
names. Second, it works around the problem in the tests by creating a
symlink from the short-name tempdir that we
On 10/20/14 4:51 PM, Peter Eisentraut wrote:
On 10/20/14 2:59 PM, Tom Lane wrote:
What do we want to do about this? I think a minimum expectation would be
for pg_basebackup to notice and complain when it's trying to create an
unworkably long symlink entry, but it would be far better if we
On 10/29/14 10:48 AM, Robert Haas wrote:
On Tue, Oct 28, 2014 at 8:29 PM, Peter Eisentraut pete...@gmx.net wrote:
On 10/20/14 2:59 PM, Tom Lane wrote:
My Salesforce colleague Thomas Fanghaenel observed that the TAP tests
for pg_basebackup fail when run in a sufficiently deeply-nested directory
On Tue, Oct 28, 2014 at 8:29 PM, Peter Eisentraut pete...@gmx.net wrote:
On 10/20/14 2:59 PM, Tom Lane wrote:
My Salesforce colleague Thomas Fanghaenel observed that the TAP tests
for pg_basebackup fail when run in a sufficiently deeply-nested directory
tree.
As for the test, we can do
On 10/20/14 2:59 PM, Tom Lane wrote:
My Salesforce colleague Thomas Fanghaenel observed that the TAP tests
for pg_basebackup fail when run in a sufficiently deeply-nested directory
tree.
As for the test, we can do something like the attached to mark the test
as TODO.
diff --git
On 10/20/14 2:59 PM, Tom Lane wrote:
What do we want to do about this? I think a minimum expectation would be
for pg_basebackup to notice and complain when it's trying to create an
unworkably long symlink entry, but it would be far better if we found a
way to cope instead.
Isn't it the
On Tue, Oct 21, 2014 at 12:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
My Salesforce colleague Thomas Fanghaenel observed that the TAP tests
for pg_basebackup fail when run in a sufficiently deeply-nested directory
tree. The cause appears to be that we rely on standard tar format
to represent
22 matches
Mail list logo
