Re: BUG #11949: pg_basebackup creates defective tar file - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject Re: BUG #11949: pg_basebackup creates defective tar file
Date
Msg-id 54801A5B.8040907@vmware.com
Whole thread Raw
In response to Re: BUG #11949: pg_basebackup creates defective tar file  (Hendrik Grewe <Hendrik.Grewe@tu-dortmund.de>)
Responses Re: BUG #11949: pg_basebackup creates defective tar file
List pgsql-bugs
On 12/03/2014 01:21 PM, Hendrik Grewe wrote:
> Am 03.12.2014 um 11:55 schrieb Heikki Linnakangas:
>>
>> The conclusion on bug-tar list seems to be that this is a bug in
>> GNU tar, and the file created by pg_basebackup is correct.
>>
>> I just wanted to add that you can work-around this by passing the
>> "-b 1" option to tar. With that, it seems to work.
>
> So the structral defect within the tarfile:
> https://lists.gnu.org/archive/html/bug-tar/2014-11/msg00007.html
>
> Is not caused by pg_basebackup?

You're referring to this, from Jörg Schilling:

> The only structural defect in the tarfile is that it contains too many bits in
> the mode field.

That shouldn't cause the --append problem. The --append problem happens
because of GNU tar's bug in handling an archive with a "blocking factor"
different from its default.

The "too many bits in the mode field" problem seems to be that we store
the file type bits that stat(2) returns in st_mode & ST_IFMT, in the
archive's mode field, while the ustar file format only expects the
permission bits to be there. Tar program will ignore the extra bits,
which is why we haven't noticed, but I guess we should fix that anyway,
for the sake of cleanliness. But that's not the root cause of the
--append corruption.

- Heikki

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE documentation or parser bug
Next
From: rseshadr@uncc.edu
Date:
Subject: BUG #12129: questions on exporting data from a database