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

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026