Thread: Missing documentation for error code: 80S01

"Donald Fraser" <postgres@kiwi-fraser.net> writes:
> Correction error code should be:
> 08S01
> and NOT
> 80S01

The reason it's not documented by us is that Postgres doesn't generate
any such error code.  Must be coming from some client-side software you
are using.

            regards, tom lane

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>


> "Donald Fraser" <postgres@kiwi-fraser.net> writes:
>> Correction error code should be:
>> 08S01
>> and NOT
>> 80S01
>
> The reason it's not documented by us is that Postgres doesn't generate
> any such error code.  Must be coming from some client-side software you
> are using.

Yes you are correct, it is coming from the PostgreSQL JDBC driver.

Thanks.

"Donald Fraser" <postgres@kiwi-fraser.net> wrote:

> I was expecting the code to be something like: crash_shutdown,
> however that appears to be under a completely different error
> class: 57P02.

If a JDBC client detects that the connection is broken, how would it
know that it is because the server crashed?

-Kevin

----- Original Message -----
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>

> "Donald Fraser" <postgres@kiwi-fraser.net> wrote:
>
>> I was expecting the code to be something like: crash_shutdown,
>> however that appears to be under a completely different error
>> class: 57P02.
>
> If a JDBC client detects that the connection is broken, how would it
> know that it is because the server crashed?
>
You are correct how could it. However the JDBC driver does know
that the server has terminated the connection and not an
IO error (via end of stream or EOF).

Is the error class "57" a better prefix for this type of error?
Knowing that the the only options for server shut down are:
Admin shut-down or Crash shut-down ?

Regards
Donald

"Donald Fraser" <postgres@kiwi-fraser.net> wrote:

> the JDBC driver does know that the server has terminated the
> connection [...] (via end of stream or EOF).
>
> Is the error class "57" a better prefix for this type of error?

Possibly.  Is it really true that the client will see a clean close
for a canceled query or a clean server shutdown and never see a
clean close of the TCP connection from the server side for other
reasons?

-Kevin

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>

> "Donald Fraser" <postgres@kiwi-fraser.net> wrote:
>
>> the JDBC driver does know that the server has terminated the
>> connection [...] (via end of stream or EOF).
>>
>> Is the error class "57" a better prefix for this type of error?
>
> Possibly.  Is it really true that the client will see a clean close
> for a canceled query or a clean server shutdown and never see a
> clean close of the TCP connection from the server side for other
> reasons?

Technically yes. When performing a read on the socket you get -1 indicating
EOF or remote socket closed. You don't get an IO error.
The difficult part is what was the client doing when the server closes the
socket?
If the client wasn't doing anything then the next likely action a client
would perform is to execute a query which would involve writing to the
socket first and in this case you will get a broken pipe IO exception,
rather than remote socket closed.
If the client had already executed a query and was attempting to read
response data then you get remote socket closed.

I would like to propose that when a "remote socket closed" is detected that
the JDBC driver uses a different error code to the one used for IO
exceptions.
Currently for IO exceptions error code is: "08S01"
For detection of remote socket closed, the error code should be different -
may be "08S02" or "57P00"?
I'm not really sure where or how these numbers are supposed to be
used/generated.
The "08" class would seem to be the most appropriate since it is
connection related.

Regards
Donald Fraser

On 13 April 2011 21:57, Donald Fraser <postgres@kiwi-fraser.net> wrote:

> Technically yes. When performing a read on the socket you get -1 indicating
> EOF or remote socket closed. You don't get an IO error.
> The difficult part is what was the client doing when the server closes the
> socket?
> If the client wasn't doing anything then the next likely action a client
> would perform is to execute a query which would involve writing to the
> socket first and in this case you will get a broken pipe IO exception,
> rather than remote socket closed.
> If the client had already executed a query and was attempting to read
> response data then you get remote socket closed.
>
> I would like to propose that when a "remote socket closed" is detected that
> the JDBC driver uses a different error code to the one used for IO
> exceptions.

If the server is shut down mid-query, doesn't the backend complete the
current query cycle before closing the connection?
i.e. we'd see ErrorResponse, ReadyForQuery, and return control to the
app before seeing EOF anyway?
The protocol spec is a bit vague there.

Oliver

From: "Oliver Jowett" <oliver@opencloud.com>
> If the server is shut down mid-query, doesn't the backend complete the
> current query cycle before closing the connection?
> i.e. we'd see ErrorResponse, ReadyForQuery, and return control to the
> app before seeing EOF anyway?
> The protocol spec is a bit vague there.

From an observation perspective only: It would seem that in the case where
the server is shut down gracefully yes, however in the case where the server
has either crashed or the connection terminated un-gracefully via software
control (for example a C funcion: elog(FATAL, "Terminating connection...");)
then no.

Donald

On Wed, Apr 13, 2011 at 6:52 AM, Donald Fraser <postgres@kiwi-fraser.net> wrote:
>> If the server is shut down mid-query, doesn't the backend complete the
>> current query cycle before closing the connection?
>> i.e. we'd see ErrorResponse, ReadyForQuery, and return control to the
>> app before seeing EOF anyway?
>> The protocol spec is a bit vague there.
>
> From an observation perspective only: It would seem that in the case where
> the server is shut down gracefully yes, however in the case where the server
> has either crashed or the connection terminated un-gracefully via software
> control (for example a C funcion: elog(FATAL, "Terminating connection...");)
> then no.

A smart shutdown waits for clients to exit on their own.  A fast or
immediate shutdown kills them immediately, even mid-query.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company