Re: Patch: incorrect array offset in backend replication tar header - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: incorrect array offset in backend replication tar header
Date
Msg-id 7134.1348787189@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: incorrect array offset in backend replication tar header  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Fri, Sep 28, 2012 at 12:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> There's no real point to using the tar format in pg_dump, really, is
> there? Which is why I think most people just don't use it.

I think folks who know the tool realize that custom format is better.
But we've seen plenty of indications that novices sometimes choose tar
format.  For instance, people occasionally complain about its
8GB-per-file limit.

> pg_basebackup in tar format is a much more useful thing, of course...

Right.

> So we could fix just pg_basebackup in backbranches (since we never
> read anything, it shouldn't be that big a problem), and then do
> pg_dump in HEAD only?

Yeah, pg_basebackup is an entirely different tradeoff.  I think we
want to fix its problems in all branches.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: data to json enhancements
Next
From: Josh Berkus
Date:
Subject: Re: MD's replication WAS Switching timeline over streaming replication