Skip site navigation (1) Skip section navigation (2)

Assertion failure with a subtransaction and cursor

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Assertion failure with a subtransaction and cursor
Date: 2009-11-22 10:30:20
Message-ID: 4B0912BC.4090803@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On all versions starting from 8.0 where subtransactions were introduced,
this causes an assertion failure:

postgres=# BEGIN;
BEGIN
postgres=# DECLARE foocur CURSOR FOR SELECT a FROM
generate_series(1,500000) a;
DECLARE CURSOR
postgres=# SAVEPOINT sp;
SAVEPOINT
postgres=# FETCH foocur;
 a
───
 1
(1 row)

postgres=# error; -- cause subxact abort
ERROR:  syntax error at or near "error"
LINE 1: error;
        ^
postgres=# ROLLBACK TO SAVEPOINT sp;
ROLLBACK
postgres=# FETCH ALL FROM foocur;
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

In server log:

TRAP: FailedAssertion("!(((file) > 0 && (file) < (int) SizeVfdCache &&
VfdCache[file].fileName != ((void *)0)))", File: "fd.c", Line: 1101)

When the first row is fetched from the cursor, the function scan is
materialized in a temporaray file. At the error, the temporary file is
deleted. But the FETCH ALL command expects the cursor to be still open,
and the file to exist, so it fails.

If assertions are disabled, you get an "ERROR:  unexpected end of tape"
error instead.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-11-22 18:01:09
Subject: Re: Assertion failure with a subtransaction and cursor
Previous:From: Hiroshi InoueDate: 2009-11-21 22:34:52
Subject: Re: BUG #5204: ODBC connection NOT working

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group