Re: BUG #11949: pg_basebackup creates defective tar file

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Hendrik Grewe <Hendrik(dot)Grewe(at)tu-dortmund(dot)de>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #11949: pg_basebackup creates defective tar file
Date: 2014-12-04 08:24:59
Message-ID: 54801A5B.8040907@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message preeti.karadi 2014-12-04 10:51:53 BUG #12141: PostgreSQL cannot be started
Previous Message dima 2014-12-04 06:43:46 BUG #12137: ORDER BY with expresion changes the output if added