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