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