Re: [HACKERS] psql casts aspersions on server reliability
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] psql casts aspersions on server reliability |
Дата | |
Msg-id | ZV957kbJfJ4BiTKU@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql casts aspersions on server reliability (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] psql casts aspersions on server reliability
|
Список | pgsql-hackers |
On Wed, Nov 22, 2023 at 10:25:14PM -0500, Bruce Momjian wrote: > On Wed, Nov 22, 2023 at 07:38:52PM -0500, Tom Lane wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > > On Wed, Sep 28, 2016 at 09:14:41AM -0400, Tom Lane wrote: > > >> I could go along with just dropping the last sentence ("This probably...") > > >> if the last error we got was FATAL level. I don't find "unexpectedly" > > >> to be problematic here: from the point of view of psql, and probably > > >> of its user, the shutdown *was* unexpected. > > > > > I looked at this thread from 2016 and I think the problem is the > > > "abnormally" word, since if the server was shutdown by the administrator > > > (most likely), it isn't abnormal. Here is a patch to remove > > > "abnormally". > > > > I do not think this is an improvement. The places you are changing > > are reacting to a connection closure. *If* we had previously gotten a > > "FATAL: terminating connection due to administrator command" message, > > then yeah the connection closure is expected; but if not, it isn't. > > Your patch adds no check for that. (As I remarked in 2016, we could > > probably condition this on the elevel being FATAL, rather than > > checking for specific error messages.) > > 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. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Вложения
В списке pgsql-hackers по дате отправления: