Missing unknown status in PGresult

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

Browse pgsql-hackers by date

  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