Skip site navigation (1) Skip section navigation (2)

Re: Patch: incorrect array offset in backend replication tar header

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Brian Weaver <cmdrclueless(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: incorrect array offset in backend replication tar header
Date: 2012-09-27 22:55:34
Message-ID: 6915.1348786534@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 09/27/2012 06:30 PM, Tom Lane wrote:
>> Having said all that, I don't think we have a lot of choices here.
>> A "tar format" output option that isn't actually tar format has hardly
>> any excuse to live at all.

> I agree, but it's possibly worth pointing out that GNU tar has no 
> trouble at all processing the erroneous format, and the "file" program 
> on my Linux system has no trouble recognizing it as a tar archive.

Well, they're falling back to assuming that the file is a pre-POSIX
tarfile, which is why you don't see string user/group names for
instance.

> Nevertheless, I think we should fix all live versions of pg_dump make 
> all live versions of pg-restore accept both formats.

I think it's clear that we should make all versions of pg_restore accept
either spelling of the magic string.  It's less clear that we should
change the output of pg_dump in back branches though.  I think the only
reason we'd not get complaints about that is that not that many people
are relying on tar-format output anyway.  Anybody who is would probably
be peeved if version 8.3.21 pg_restore couldn't read the output of
version 8.3.22 pg_dump.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2012-09-27 22:58:29
Subject: Re: data to json enhancements
Previous:From: Magnus HaganderDate: 2012-09-27 22:53:20
Subject: Re: Patch: incorrect array offset in backend replication tar header

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group