Thread: psql no longer handles fatal/panic errors well

psql no longer handles fatal/panic errors well

From
Tom Lane
Date:
The following test cases were created by modifying int4div and int2div
to produce FATAL and PANIC, respectively, instead of plain ERROR for
division-by-zero.

Using an older psql, all is well:

template1=# select 2/0;
FATAL:  division by zero
server closed the connection unexpectedly       This probably means the server terminated abnormally       before or
whileprocessing the request.
 
The connection to the server was lost. Attempting reset: Succeeded.
template1=# select 1::int2/0::int2;
PANIC:  division by zero
server closed the connection unexpectedly       This probably means the server terminated abnormally       before or
whileprocessing the request.
 
The connection to the server was lost. Attempting reset: Failed.
!# 

Using CVS-tip psql, things are weird:

template1=# select 2/0;
The connection to the server was lost. Attempting reset: Succeeded.
FATAL:  division by zero
server closed the connection unexpectedly       This probably means the server terminated abnormally       before or
whileprocessing the request.
 
template1=# select 1::int2/0::int2;
The connection to the server was lost. Attempting reset: Failed.
connection pointer is NULL
!> 

It seems odd that the FATAL error is reported after, rather than before,
the reconnection attempt; and it's really not acceptable to lose the
PANIC message entirely.

I checked that the server does still fflush the message before dying,
so the problem is on the client side.  It's possible that my recent
libpq hacks have something to do with it, but I don't think libpq is
at fault for the connection retry occuring before the message is
printed.  Any idea what was changed?
        regards, tom lane


Re: psql no longer handles fatal/panic errors well

From
Tom Lane
Date:
I said:
> It seems odd that the FATAL error is reported after, rather than before,
> the reconnection attempt; and it's really not acceptable to lose the
> PANIC message entirely.

Also, both classes of messages seem to be dropped if psql is not running
interactively (probably since it exits without trying to reconnect).
If I run the regression tests against my hacked backend, the errors test
fails with:

--- 241,244 ---- -- Check that division-by-zero is properly caught. -- select 1/0;
! connection to server was lost

======================================================================
        regards, tom lane