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

On 09/27/2012 06:30 PM, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Tue, Sep 25, 2012 at 4:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'm a bit concerned about backwards compatibility issues. It looks to
>>> me like existing versions of pg_restore will flat out reject files that
>>> have a spec-compliant "ustar\0" MAGIC field. Is it going to be
>>> sufficient if we fix this in minor-version updates, or are we going to
>>> need to have a switch that tells pg_dump to emit the incorrect old
>>> format? (Ick.)
>> Do we officially support using an older pg_restore to reload a newer
>> dump? I think not? As long as we don't officially support that, I
>> think we'll be ok.
> Well, for the -Fc format, we have an explicit version number, and
> pg_restore is supposed to be able to read anything with current or prior
> version number. We don't bump the version number too often, but we've
> definitely done it anytime we added new features at the file-format
> level. However, since the whole point of the -Ft format is to be
> standard-compliant, people might be surprised if it fell over in a
> backwards-compatibility situation.
>
> 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.

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

cheers

andrew