| 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: | Whole Thread | Raw Message | 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
| 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 |