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

Alfred Perlstein <bright@wintelcom.net> writes:
> I'm pretty sure I know what to do now, it's pretty simple actually,
> I can examine the state of the connection, if it's in PGASYNC_COPY_IN
> then I don't grow the buffer, I inform the application that the 
> data will block, if it's no PGASYNC_COPY_IN I allow the buffer to grow
> protecting the application from blocking.

From what I recall of the prior discussion, it seemed that a state-based
approach probably isn't the way to go.  The real issue is how many
routines are you going to have to change to deal with a three-way return
convention; you want to minimize the number of places that have to cope
with that.  IIRC the idea was to let pqPutBytes grow the buffer so that
its callers didn't need to worry about a "sorry, won't block" return
condition.  If you feel that growing the buffer is inappropriate for a
specific caller, then probably the right answer is for that particular
caller to make an extra check to see if the buffer will overflow, and
refrain from calling pqPutBytes if it doesn't like what will happen.

If you make pqPutByte's behavior state-based, then callers that aren't
expecting a "won't block" return will fail (silently :-() in some states.
While you might be able to get away with that for PGASYNC_COPY_IN state
because not much of libpq is expected to be exercised in that state,
it strikes me as an awfully fragile coding convention.  I think you will
regret that choice eventually, if you make it.
        regards, tom lane