BUG #15379: Release process of the index access method is not called when an error occurs.

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: do(dot)daisuke(at)gmail(dot)com
Subject: BUG #15379: Release process of the index access method is not called when an error occurs.
Date: 2018-09-11 04:56:08
Message-ID: 153664176892.23144.11307374381540165215@wrigleys.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 15379
Logged by: Daisuke Ando
Email address: do(dot)daisuke(at)gmail(dot)com
PostgreSQL version: 9.5.14
Operating system: CentOS6 64bit
Description:

When an error occurs in `SELECT FOR UPDATE` using an index, release process
of the index access method is not called.

How to reproduce :

Prepare an indexed table.
```
CREATE TABLE a (
id int
);
CREATE INDEX b ON a (id);
```
Open one connection and insert a record.
```
INSERT INTO a VALUES (1);
```
Open another connection and lock the record.
```
-- another connection
BEGIN;
SELECT * FROM a WHERE id = 1 FOR UPDATE;
-- keep connecting without leaving
```
The first connection is locked in the same way, but if it can not be locked
with NOWAIT, it makes an error.
```
-- first connection(insert record)
BEGIN;
SELECT * FROM a WHERE id = 1 FOR UPDATE NOWAIT;
-- ERROR: could not obtain lock on row in relation "a"
```
At this time, the index access method ambeginscan() is called but since
amendscan() is not called, ambeginscan() can not properly release the
resource set in IndexScanDesc::opaque.

Document:
https://www.postgresql.org/docs/9.5/static/index-functions.html

In this example we use the btree index so the corresponding ambeginscan() is
btbeginscan() and amendscan() is btendscan().
If you set a breakpoint for these two functions in the debugger, it is
confirmed that there is not enough call to btendscan() once when an error
occurs (the number of calls to btendscan() is less than the number of calls
to btbeginscan()) it can.

Solution:
For example, if an error occurs while calling PortalRun() in
exec_simple_query() of src/backend/tcop/postgresq.c, amendscan() will not be
called because PortalDrop() will not be called. Therefore, it is good to
postpone even when an error occurs as follows.

```
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 7a9ada2c71..daa6228535 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -1116,16 +1116,28 @@ exec_simple_query(const char *query_string)
*/
MemoryContextSwitchTo(oldcontext);

- /*
- * Run the portal to completion, and then drop it (and the receiver).
- */
- (void) PortalRun(portal,
- FETCH_ALL,
- true, /* always top level */
- true,
- receiver,
- receiver,
- completionTag);
+ PG_TRY();
+ {
+ /*
+ * Run the portal to completion, and then drop it (and the receiver).
+ */
+ (void) PortalRun(portal,
+ FETCH_ALL,
+ true, /* always top level */
+ true,
+ receiver,
+ receiver,
+ completionTag);
+ }
+ PG_CATCH();
+ {
+ receiver->rDestroy(receiver);
+
+ PortalDrop(portal, false);
+
+ PG_RE_THROW();
+ }
+ PG_END_TRY();

receiver->rDestroy(receiver);
```

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2018-09-11 05:30:35 Re: BUG #15379: Release process of the index access method is not called when an error occurs.
Previous Message Andrew Gierth 2018-09-11 03:13:21 Re: BUG #15378: SP-GIST memory context screwup?