From: | Hao Wu <hawu(at)vmware(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Asim Praveen <pasim(at)vmware(dot)com>, Simon Gao <simong(at)vmware(dot)com> |
Subject: | Missing unknown status in PGresult |
Date: | 2020-08-13 02:12:13 |
Message-ID: | CY4PR0501MB3906E4E32928FF6DBE0D75F3A4430@CY4PR0501MB3906.namprd05.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
PGRES_FATAL_ERROR is the result status in most cases in the client-side when the backend process raises an error. When the query is failed to execute, PGRES_FATAL_ERROR is returned.
But in another case, PGRES_FATAL_ERROR is also returned. The situation is that the network is broken between the client and the backend immediately after the backend process has committed locally. So the client gets the same result status(PGRES_FATAL_ERROR) with normal errors(transaction failed). But the transaction is actually succeeded.
When the libpq detects an EOF, a PGresult with status PGRES_FATAL_ERROR is returned to the client.
We can check the error message in PGresult to see why an error is returned, but it's unlikely reliable and tricky.
The result status should be unknown in the above case. Because the server has received the request, and the client doesn't get any response from the server, so it may succeed or fail.
Regards,
Hao Wu
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-08-13 02:37:21 | Re: Parallel query hangs after a smart shutdown is issued |
Previous Message | Michael Paquier | 2020-08-13 01:29:42 | Re: run pgindent on a regular basis / scripted manner |