AW: [HACKERS] Re: light dawns: serious bug in FE/BE protocol hand ling - Mailing list pgsql-hackers

From Zeugswetter Andreas IZ5
Subject AW: [HACKERS] Re: light dawns: serious bug in FE/BE protocol hand ling
Date
Msg-id 219F68D65015D011A8E000006F8590C60267B351@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
> > 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.
> 
I think a NOTICE, could be handeled differently than ERROR, since by
definition a NOTICE won't "disturb" the current transaction, while an
ERROR will do an automatic rollback. So I think the ERROR case should 
stop transmission to the client immediately and then send the ERROR.
This happens with other DBMS's e.g when a lock timeout has occurred,
or the good old "Snapshot too old" happens. (unload files will be half
finished). 
The NOTICE could probably be buffered until the end of current data.

Andreas



pgsql-hackers by date:

Previous
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] A patch for FATAL 1:btree: BTP_CHAIN flag was expected
Next
From: Oleg Bartunov
Date:
Subject: Re: [INTERFACES] CASE tools? (slightly off-topic)