Re: [HACKERS] psql casts aspersions on server reliability
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] psql casts aspersions on server reliability |
Дата | |
Msg-id | ZWC_AfdviG6pwPv1@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql casts aspersions on server reliability (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: [HACKERS] psql casts aspersions on server reliability
|
Список | pgsql-hackers |
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 > > stuctured 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 labled as "abnormal". -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Вложения
В списке pgsql-hackers по дате отправления: