From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: elog() patch |
Date: | 2002-03-03 23:40:13 |
Message-ID: | 12601.1015198813@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> I am thinking of inventing an additional elog level, perhaps called
>> COMMERR, to be used specifically for reports of client communication
>> trouble. This could be treated the same as LOG as far as output to
>> the server log goes, but we would hard-wire it to never be reported
>> to the client (for fear of recursive failure).
> Couldn't we just set whereToSendOutput to None to fix this, or is there
> a sense that we may be able to send messages later.
We might as well just do proc_exit() as do that: once you reset
whereToSendOutput, you are effectively done talking to the client
(because SELECT won't send results to the client anymore). The
errors that libpq notices might or might not be hard failures, but
I don't want to take the approach of changing global state in order
to report them.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-03-03 23:42:17 | Re: elog() patch |
Previous Message | Bruce Momjian | 2002-03-03 23:27:43 | Re: elog() patch |