Thread: Re: [ADMIN] Missing documentation for error code: 80S01

----- 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