Re: [GENERAL] Large object corruption during 'piped' pg_restore - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [GENERAL] Large object corruption during 'piped' pg_restore
Date
Msg-id AANLkTimOBqtnTTK22vdrXmcX3BH7Dyc+koeDrVuQ9mBW@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Large object corruption during 'piped' pg_restore  (Bosco Rama <postgres@boscorama.com>)
Responses Re: [GENERAL] Large object corruption during 'piped' pg_restore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 21, 2011 at 12:44 PM, Bosco Rama <postgres@boscorama.com> wrote:
> Tom Lane wrote:
>>
>> So I'm not sure whether to fix it, or leave it as a known failure case
>> in old branches.  Comments?
>
> I understand the reluctance to fool with stable code.  I have zero insight
> into your installed versions distribution and backward compatibility needs
> so any comment I may have here is purely selfish.
>
> As an end user there is one area of the DB that I want to work correctly
> 100% of the time and that is the dump/restore tool(s).  If it's not going
> to work under certain circumstances it should at least tell me so and
> fail.  I don't think having the tool appear to work while corrupting the
> data (even if documented as doing so) is a viable method of operation.

Yeah, I lean toward saying we should back-patch this.  Yeah, it'll be
lightly tested, but it's a pretty confined change, so it's unlikely to
break anything else.  ISTM the worst case scenario is that it takes
two minor releases to get it right, and even that seems fairly
unlikely.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Moving test_fsync to /contrib?
Next
From: Tom Lane
Date:
Subject: Re: Sync Rep for 2011CF1