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, Pennsylvania 19026