AW: [HACKERS] Re: light dawns: serious bug in FE/BE protocol hand ling

From: Zeugswetter Andreas IZ5 <Andreas(dot)Zeugswetter(at)telecom(dot)at>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: AW: [HACKERS] Re: light dawns: serious bug in FE/BE protocol hand ling
Date: 1999-04-26 07:00:46
Message-ID: 219F68D65015D011A8E000006F8590C60267B351@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Mariusz Czułada 1999-04-26 07:01:17 CASE tools? (slightly off-topic)
Previous Message Jan Wieck 1999-04-26 06:57:27 Re: [HACKERS] create view as select distinct (fwd)