Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster)
Date
Msg-id 5120.948606837@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster)  (Alfred Perlstein <bright@wintelcom.net>)
Responses Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster)
List 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 by date:

Previous
From: Vince Vielhaber
Date:
Subject: Re: [HACKERS] Happy column dropping
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Happy column dropping