Re: [GENERAL] Large object corruption during 'piped' pg_restore

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [GENERAL] Large object corruption during 'piped' pg_restore
Дата
Msg-id AANLkTimOBqtnTTK22vdrXmcX3BH7Dyc+koeDrVuQ9mBW@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Large object corruption during 'piped' pg_restore  (Bosco Rama <postgres@boscorama.com>)
Ответы Re: [GENERAL] Large object corruption during 'piped' pg_restore  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Moving test_fsync to /contrib?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Sync Rep for 2011CF1