public inbox for [email protected]
help / color / mirror / Atom feedpsql casts aspersions on server reliability
5+ messages / 4 participants
[nested] [flat]
* psql casts aspersions on server reliability
@ 2016-09-28 12:22 Robert Haas <[email protected]>
2016-09-28 13:14 ` Re: psql casts aspersions on server reliability Tom Lane <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Robert Haas @ 2016-09-28 12:22 UTC (permalink / raw)
To: pgsql-hackers
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:
1. It says the server closed the connection unexpectedly, but it just
finished processing a FATAL message from the server. So how
unexpected is it that the connection would thereafter be closed?
2. It says the server probably terminated abnormally, but PostgreSQL
is rarely so unreliable as to just give up the ghost and die. The
ErrorResponse it just processed has an errcode of
ERRCODE_ADMIN_SHUTDOWN, so probably what happened is somebody either
shut down the server or killed the session.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: psql casts aspersions on server reliability
2016-09-28 12:22 psql casts aspersions on server reliability Robert Haas <[email protected]>
@ 2016-09-28 13:14 ` Tom Lane <[email protected]>
2016-09-28 14:22 ` Re: psql casts aspersions on server reliability Robert Haas <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2016-09-28 13:14 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
Robert Haas <[email protected]> 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: psql casts aspersions on server reliability
2016-09-28 12:22 psql casts aspersions on server reliability Robert Haas <[email protected]>
2016-09-28 13:14 ` Re: psql casts aspersions on server reliability Tom Lane <[email protected]>
@ 2016-09-28 14:22 ` Robert Haas <[email protected]>
2016-09-28 15:13 ` Re: psql casts aspersions on server reliability David Steele <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Robert Haas @ 2016-09-28 14:22 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
On Wed, Sep 28, 2016 at 9:14 AM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: psql casts aspersions on server reliability
2016-09-28 12:22 psql casts aspersions on server reliability Robert Haas <[email protected]>
2016-09-28 13:14 ` Re: psql casts aspersions on server reliability Tom Lane <[email protected]>
2016-09-28 14:22 ` Re: psql casts aspersions on server reliability Robert Haas <[email protected]>
@ 2016-09-28 15:13 ` David Steele <[email protected]>
2016-09-28 18:23 ` Re: psql casts aspersions on server reliability Petr Jelinek <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: David Steele @ 2016-09-28 15:13 UTC (permalink / raw)
To: Robert Haas <[email protected]>; Tom Lane <[email protected]>; +Cc: pgsql-hackers
On 9/28/16 10:22 AM, Robert Haas wrote:
> On Wed, Sep 28, 2016 at 9:14 AM, Tom Lane <[email protected]> wrote:
>> Robert Haas <[email protected]> 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
[email protected]
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: psql casts aspersions on server reliability
2016-09-28 12:22 psql casts aspersions on server reliability Robert Haas <[email protected]>
2016-09-28 13:14 ` Re: psql casts aspersions on server reliability Tom Lane <[email protected]>
2016-09-28 14:22 ` Re: psql casts aspersions on server reliability Robert Haas <[email protected]>
2016-09-28 15:13 ` Re: psql casts aspersions on server reliability David Steele <[email protected]>
@ 2016-09-28 18:23 ` Petr Jelinek <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Petr Jelinek @ 2016-09-28 18:23 UTC (permalink / raw)
To: David Steele <[email protected]>; Robert Haas <[email protected]>; Tom Lane <[email protected]>; +Cc: 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 <[email protected]> wrote:
>>> Robert Haas <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2016-09-28 18:23 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-09-28 12:22 psql casts aspersions on server reliability Robert Haas <[email protected]>
2016-09-28 13:14 ` Tom Lane <[email protected]>
2016-09-28 14:22 ` Robert Haas <[email protected]>
2016-09-28 15:13 ` David Steele <[email protected]>
2016-09-28 18:23 ` Petr Jelinek <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox