Re: SQLSTATE when PostgreSQL crashes during COMMIT statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Takahashi, Ryohei" <r(dot)takahashi_2(at)jp(dot)fujitsu(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, "'Andreas Kretschmer'" <andreas(at)a-kretschmer(dot)de>, "'Francisco Olarte'" <folarte(at)peoplecall(dot)com>
Subject: Re: SQLSTATE when PostgreSQL crashes during COMMIT statement
Date: 2019-04-16 14:31:14
Message-ID: 26881.1555425074@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Takahashi, Ryohei" <r(dot)takahashi_2(at)jp(dot)fujitsu(dot)com> writes:
>> So, if the library gives you an error ( "I have not received the commit
>> confirmation" , not something like "commit failed" ), you will still
>> need to test the data, if you can, to know how the server come back up.

> Yes.
> I want to know what error does library give to the application on such case.
> I supposed it is certain SQLSTATE.

libpq, at least, doesn't produce SQLSTATEs for errors that it detects.
(It probably should, but that's been a TODO item for a couple of
decades now ... so don't hold your breath.) So the best you can do here
is to check the error message spelling.

A crude but possibly sufficient approach is to assume that once you've
got a working connection, *any* error that lacks a SQLSTATE is indicative
of connection loss. This idea could fail for cases like out-of-memory,
but if your app is at the edge of OOM then giving up might be wise anyway.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2019-04-16 14:42:28 Re: Alter domain type / avoiding table rewrite
Previous Message Adrian Klaver 2019-04-16 14:28:16 Re: Alter domain type / avoiding table rewrite