Re: psql casts aspersions on server reliability

Поиск
Список
Период
Сортировка
От Petr Jelinek
Тема Re: psql casts aspersions on server reliability
Дата
Msg-id a6350de3-843a-6317-5e96-fb8915e49328@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: psql casts aspersions on server reliability  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On 28/09/16 17:13, David Steele wrote:
> On 9/28/16 10:22 AM, Robert Haas wrote:
>> On Wed, Sep 28, 2016 at 9:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> psql tends to do things like this:
>>>> rhaas=# select * from pg_stat_activity;
>>>> FATAL:  terminating connection due to administrator command
>>>> server closed the connection unexpectedly
>>>>     This probably means the server terminated abnormally
>>>>     before or while processing the request.
>>>
>>>> Basically everything psql has to say about this is a lie:
>>>
>>> I cannot get terribly excited about this.  What you seem to be proposing
>>> is that psql try to intuit the reason for connection closure from the
>>> last error message it got, but that seems likely to lead to worse lies
>>> than printing a boilerplate message.
>>>
>>> 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 don't care very much whether we try to intuit the reason for
>> connection closure or not; it could be done, but I don't feel that it
>> has to be done.  My bigger point is that currently psql speculates
>> that the reason for *every* connection closure is abnormal server
>> termination, which is actually a very rare event.
>>
>> It may have been common when that message was added.
>> 1a17447be1186fdd36391c58a2a0209f613d89c4 changed the wording this
>> message in 2001, and the original message seems to date to
>> 011ee13131f6fa2f6dbafd3827b70d051cb28f64 in 1996.  And my guess is at
>> that time the server probably did just roll over and die with some
>> regularity.  But today it usually doesn't.  It's neither helpful nor
>> good PR for libpq to guess that the most likely cause of a server
>> disconnection is server unreliability.
>>
>> I have seen actual instances of customers getting upset by this
>> message even though the server had been shut down quite cleanly.  The
>> message got into a logfile and induced minor panic.  Fortunately, I
>> have not seen this happen lately.
> 
> +1 for making this error message less frightening.  I have also had to
> explain it away on occasion.
> 

+1 I've seen this being misleading way too often.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Tuplesort merge pre-reading
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: should xlog_outdesc modify its argument?