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 bec
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 subscr
On Fri, Nov 7, 2014 at 9:03 PM, Peter Eisentraut 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 in the t
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 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 all kinds of
On 1/7/15 3:19 PM, Robert Haas wrote:
> On Tue, Jan 6, 2015 at 4:33 PM, Peter Eisentraut 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? Secon
On Tue, Jan 6, 2015 at 4:33 PM, Peter Eisentraut 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 of putting
On Wed, Jan 7, 2015 at 3:03 AM, Peter Eisentraut wrote:
>
> On 12/27/14 8:02 PM, Robert Haas wrote:
> > On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut
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
On 12/27/14 8:02 PM, Robert Haas wrote:
> On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut 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 h
On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut 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 stil
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 possib
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 so
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
On Tue, Dec 23, 2014 at 4:10 AM, Oskari Saarenmaa 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 s
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
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
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
On 10/29/14 10:48 AM, Robert Haas wrote:
> On Tue, Oct 28, 2014 at 8:29 PM, Peter Eisentraut 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
>>> tr
On Tue, Oct 28, 2014 at 8:29 PM, Peter Eisentraut 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 something li
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 a/src/bin/
On Tue, Oct 21, 2014 at 12:29 AM, 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. The cause appears to be that we rely on standard "tar" format
> to represent the symlink
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 ba
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 the symlink for a tablespace, and POSIX tar format has a
hard-wired restr
23 matches
Mail list logo
