Re: [HACKERS] Re: light dawns: serious bug in FE/BE protocol handling

> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> This is messy, but I think it beats the alternatives --- unless someone
> >> has a better idea?  (I don't think redoing the FE/BE protocol yet again
> >> is very attractive at this stage.)
> 
> > That's a tough one.  Why are elog(NOTICE) being sent?  Is there a way to
> > buffer those instead?
> 
> I thought about that, but gave it up when I realized that it doesn't
> offer a solution to the elog(ERROR) case.  The only way not to choke
> for elog(ERROR) is not to start sending the data message until you've
> constructed it completely --- or to have a way of aborting the partially
> sent message, which is feasible for COPY OUT but not really practical
> for SELECT data messages.

If you get elog(ERROR), can't you just abort the current message, and
send the elog(), or is it very involved.

> The particular case I saw last night involved get_groname() complaining
> during an attempt to display an incorrect ACL, but that's not very
> interesting.  The real reason that I'm so exercised about this is that
> intermittent NOTICE-embedded-in-data-message failures are exactly the
> thing that forced my company to give up using 6.3.2 last summer and
> put our production application on pre-alpha 6.4.  Talk about nervous.
> We lived to tell the tale, but I didn't like it one bit.

Hmmm.

> At the time I didn't understand what was causing the problem, but now
> I realize that 6.4 had simply masked the fundamental protocol problem
> by eliminating the particular NOTICE condition (sorry I don't remember
> exactly what that NOTICE was).  That bug is still there waiting to bite
> me again, and I aim to squash it before it can.

Yes, I vaguelly remember that.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026