Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster)
Дата
Msg-id 5120.948606837@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster)  (Alfred Perlstein <bright@wintelcom.net>)
Ответы Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster)  (Alfred Perlstein <bright@wintelcom.net>)
Список pgsql-hackers
Alfred Perlstein <bright@wintelcom.net> writes:
> I really hope the originator of the problem report will get back to
> us to make sure it's settled.

> *poking Patrick Welche*

Um, I didn't have any trouble at all reproducing Patrick's complaint.
pg_dump any moderately large table (I used tenk1 from the regress
database) and try to load the script with psql.  Kaboom.

Also, I still say that turning off nonblock mode by default is only
a band-aid: this code *will fail* whenever nonblock mode is enabled,
because it does not return enough info to the caller to allow the
caller to do the right thing.  If you haven't seen it fail, that
only proves that you haven't actually stressed it to the point of
exercising the buffer-overrun code paths.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vince Vielhaber
Дата:
Сообщение: Re: [HACKERS] Happy column dropping
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Happy column dropping