On Fri, Nov 24, 2023 at 10:19:29AM -0500, Bruce Momjian wrote:
> On Fri, Nov 24, 2023 at 04:06:22AM +0100, Laurenz Albe wrote:
> > On Thu, 2023-11-23 at 11:12 -0500, Bruce Momjian wrote:
> > > On Wed, Nov 22, 2023 at 10:25:14PM -0500, Bruce Momjian wrote:
> > > > Yes, you are correct. Here is a patch that implements the FATAL test,
> > > > though I am not sure I have the logic correct or backwards, and I don't
> > > > know how to test this. Thanks.
> > >
> > > I developed the attached patch which seems to work better. In testing
> > > kill -3 on a backend or calling elog(FATAL) in the server for a
> > > session, libpq's 'res' is NULL, meaning we don't have any status to
> > > check for PGRES_FATAL_ERROR. It is very possible that libpq just isn't
> > > structured to have the PGRES_FATAL_ERROR at the point where we issue this
> > > message, and this is not worth improving.
> > >
> > > test=> select pg_sleep(100);
> > > --> FATAL: FATAL called
> > >
> > > server closed the connection unexpectedly
> > > --> This probably means the server terminated null
> > > before or while processing the request.
> > > The connection to the server was lost. Attempting reset: Succeeded.
> >
> > I don't thing "terminated null" is a meaningful message.
>
> Yes, this is just a debug build so we can see the values of 'res'.
> Sorry for the confusion. This attached patch has the elog() added so
> you can reproduce what I saw.
>
> I am actually unclear which exits should be labeled as "abnormal".
There are five call sites which issue this message, so I looked at
adding "abnormally" just at the call sites where it made sense, but I
couldn't find a pattern. I don't plan to pursue this further.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.