Re: psql casts aspersions on server reliability

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: psql casts aspersions on server reliability
Дата
Msg-id 369be187-8843-32da-17d6-cb64ad2c2154@pgmasters.net
обсуждение исходный текст
Ответ на Re: psql casts aspersions on server reliability  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: psql casts aspersions on server reliability  (Petr Jelinek <petr@2ndquadrant.com>)
Список pgsql-hackers
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.

-- 
-David
david@pgmasters.net



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

Предыдущее
От: David Steele
Дата:
Сообщение: Re: PATCH: Exclude additional directories in pg_basebackup
Следующее
От: Robert Haas
Дата:
Сообщение: Re: assert violation in logical messages serialization