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

* Tom Lane  [001012 12:14] wrote:
> Alfred Perlstein  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.

It is a somewhat fragile change, but much less intrusive than anything
else I could think of.  It removes the three-way return value from
the send code for everything except when in a COPY IN state where
it's the application's job to handle it.  If there would be a
blocking condition we do as the non-blocking code handles it except
instead of blocking we buffer it in it's entirety.

My main question was wondering if there's any cases where we might 
"go nuts" sending data to the backend with the exception of the 
COPY code?

-- or --

I could make a function to check the buffer space and attempt to
flush the buffer (in a non-blocking manner) to be called from
PQputline and PQputnbytes if the connection is non-blocking.

However since those are external functions my question is if you
know of any other uses for those function besideds when COPY'ing
into the backend?

Since afaik I'm the only schmoe using my non-blocking stuff,
restricting the check for bufferspace to non-blocking connections
wouldn't break any APIs from my PoV.

How should I proceed?

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."