Thread: [Fwd: ERROR: cannot extract system attribute from minimal tuple]

-------- Пересылаемое сообщение --------
От: Denis Feklushkin <denis.feklushkin@gmail.com>
Кому: submit@bugs.debian.org
Тема: ERROR: cannot extract system attribute from minimal tuple
Дата: Sat, 05 Feb 2011 09:50:06 +0700

Package: postgresql-9.0
Version: 9.0.3-1
Severity: normal
Tags: upstream

Query:

SELECT currency_id1
FROM bug0.currency_pairs p
FOR SHARE;

returns error:
ERROR:  cannot extract system attribute from minimal tuple

Schema:

---------------------------
CREATE SCHEMA bug0;

SET search_path = bug0, pg_catalog;

CREATE VIEW insider AS
    SELECT true AS insider;

CREATE TABLE pairs (
    currency_id1 text,
    currency_id2 text,
    hidden boolean,
    pair_id integer
);

CREATE VIEW currency_pairs AS
    SELECT p.pair_id, p.currency_id1, p.currency_id2
    FROM (pairs p CROSS JOIN insider i) WHERE ((NOT p.hidden) OR
i.insider)
ORDER BY p.pair_id;

COPY pairs (currency_id1, currency_id2, hidden, pair_id) FROM stdin;
BTC     RUB     f       1
\.

---------------------------

Excerpts from Denis Feklushkin's message of mié feb 09 16:53:28 -0300 2011:

> Query:
>
> SELECT currency_id1
> FROM bug0.currency_pairs p
> FOR SHARE;
>
> returns error:
> ERROR:  cannot extract system attribute from minimal tuple

Hmm, yeah, in an assert-enabled build of HEAD it dies with:

TRAP: FailedAssertion(«!(attno > 0)», Archivo: «/pgsql/source/HEAD/src/backend/executor/execJunk.c», Línea: 251)

I don't have time to track this down right now ...

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Hmm, yeah, in an assert-enabled build of HEAD it dies with:

> TRAP: FailedAssertion(«!(attno > 0)», Archivo: «/pgsql/source/HEAD/src/backend/executor/execJunk.c», Línea: 251)

> I don't have time to track this down right now ...

It's a shortcoming in the PlanRowMark+resjunk column data structure:
when we flatten subqueries, the rangetable indexes of the relations
to be row-locked can change, but the resjunk column names already
assigned to represent their ctid's aren't updated.  Working on a
fix now.

            regards, tom lane