Re: failed to fetch tuple for EvalPlanQual recheck

Hello.

This is a bug report.
When I tested in PostgreSQL9 beta3,I got an error.

==================================================
select * from part_bug where HIRENUM=4 for update;
failed to fetch tuple for EvalPlanQual recheck
==================================================

Is this error assumed?

Environment.
Postgresql:9.0 beta3
OS :CentOS5.3

Reproduce Case
1)Make a partitioned table.

CREATE TABLE part_bug
(EMPNO INT,
ENAME VARCHAR(10),
HIRENUM int,
DEPTNO INT,
LOCATION VARCHAR(20));

CREATE TABLE part_bug_1 ( CHECK ( HIRENUM >= 1 AND HIRENUM < 2) )
INHERITS (part_bug);
CREATE TABLE part_bug_2 ( CHECK ( HIRENUM >= 2 AND HIRENUM < 3) )
INHERITS (part_bug);
CREATE TABLE part_bug_3 ( CHECK ( HIRENUM >= 3 AND HIRENUM < 4) )
INHERITS (part_bug);
CREATE TABLE part_bug_4 ( CHECK ( HIRENUM >= 4 AND HIRENUM < 5) )
INHERITS (part_bug);
CREATE TABLE part_bug_5 ( CHECK ( HIRENUM >= 5 AND HIRENUM < 6) )
INHERITS (part_bug);
CREATE TABLE part_bug_6 ( CHECK ( HIRENUM >= 6 AND HIRENUM < 7) )
INHERITS (part_bug);
CREATE TABLE part_bug_7 ( CHECK ( HIRENUM >= 7 AND HIRENUM < 8) )
INHERITS (part_bug);
CREATE TABLE part_bug_8 ( CHECK ( HIRENUM >= 8 AND HIRENUM < 9) )
INHERITS (part_bug);
CREATE TABLE part_bug_9 ( CHECK ( HIRENUM >= 9 AND HIRENUM < 10) )
INHERITS (part_bug);
CREATE TABLE part_bug_10 ( CHECK ( HIRENUM >= 10 AND HIRENUM < 11) )
INHERITS (part_bug);

CREATE OR REPLACE FUNCTION part_range_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
IF ( NEW.HIRENUM >= 1 AND NEW.HIRENUM < 2) THEN INSERT INTO part_bug_1
VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 2 AND NEW.HIRENUM < 3) THEN INSERT INTO
part_bug_2 VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 3 AND NEW.HIRENUM < 4) THEN INSERT INTO
part_bug_3 VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 4 AND NEW.HIRENUM < 5) THEN INSERT INTO
part_bug_4 VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 5 AND NEW.HIRENUM < 6) THEN INSERT INTO
part_bug_5 VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 6 AND NEW.HIRENUM < 7) THEN INSERT INTO
part_bug_6 VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 7 AND NEW.HIRENUM < 8) THEN INSERT INTO
part_bug_7 VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 8 AND NEW.HIRENUM < 9) THEN INSERT INTO
part_bug_8 VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 9 AND NEW.HIRENUM < 10) THEN INSERT INTO
part_bug_9 VALUES (NEW.*);
ELSIF ( NEW.HIRENUM >= 10 AND NEW.HIRENUM < 11) THEN INSERT INTO
part_bug_10 VALUES (NEW.*);
ELSE
RAISE EXCEPTION 'HIRENUM out of range. Fix the
part_range_insert_trigger() function!';
END IF;
RETURN NULL;
END;
$$
LANGUAGE plpgsql;

CREATE TRIGGER part_range_insert_trigger
BEFORE INSERT ON part_bug
FOR EACH ROW EXECUTE PROCEDURE part_range_insert_trigger();

insert into part_bug values(4,'B',4,4,'B');

2)Reproduce the error.We need two sessions.

SESSION A)
begin;
select * from part_bug where HIRENUM=4 for update;

SESSION B)
begin;
select * from part_bug where HIRENUM=4 for update;
--lock wait

SESSION A)
update part_bug set ename='B' where HIRENUM in (4);
end;

Then the error is returned on session B.

The error needs a partition table and
never happens in 8.4.4.

Thank you.

Excerpts from Kenichiro Tanaka's message of dom jul 25 21:01:01 -0400 2010:

> This is a bug report.
> When I tested in PostgreSQL9 beta3,I got an error.
>
> ==================================================
> select * from part_bug where HIRENUM=4 for update;
> failed to fetch tuple for EvalPlanQual recheck
> ==================================================
>
> Is this error assumed?

Hmm, I don't see just an error message here, but an assertion failure:

TRAP: FailedAssertion(«!(((bool) (((void*)(tid) != ((void *)0)) && ((tid)->ip_posid != 0))))», Archivo: «/pgsql/source/990_rel/src/backend/access/heap/heapam.c», Línea: 1400)

This is the backtrace:

#2 0x00000000006f6e0d in ExceptionalCondition (
conditionName=<value optimized out>, errorType=<value optimized out>,
fileName=<value optimized out>, lineNumber=<value optimized out>)
at /pgsql/source/990_rel/src/backend/utils/error/assert.c:57
#3 0x00000000004773cc in heap_fetch (relation=0x7f8fafc62c80,
snapshot=<value optimized out>, tuple=0x7fffdda09950,
userbuf=<value optimized out>, keep_buf=0 '\000',
stats_relation=0x7f8fafcd95ec)
at /pgsql/source/990_rel/src/backend/access/heap/heapam.c:1400
#4 0x000000000058a936 in ExecLockRows (node=0x27a4800)
at /pgsql/source/990_rel/src/backend/executor/nodeLockRows.c:203
#5 0x0000000000576968 in ExecProcNode (node=0x27a4800)
at /pgsql/source/990_rel/src/backend/executor/execProcnode.c:466
#6 0x000000000057569e in ExecutePlan (queryDesc=0x274f608, direction=946,
count=0) at /pgsql/source/990_rel/src/backend/executor/execMain.c:1190

On Tue, Jul 27, 2010 at 04:13:56PM -0400, Alvaro Herrera wrote:
> Excerpts from Kenichiro Tanaka's message of dom jul 25 21:01:01 -0400 2010:
>
> > This is a bug report.
> > When I tested in PostgreSQL9 beta3,I got an error.
> >
> > ==================================================
> > select * from part_bug where HIRENUM=4 for update;
> > failed to fetch tuple for EvalPlanQual recheck
> > ==================================================
> >
> > Is this error assumed?
> Hmm, I don't see just an error message here, but an assertion failure:
I guess youve compiled with --enable-cassert and Kenchiro-san has not?

Andres

Excerpts from Andres Freund's message of mar jul 27 17:20:37 -0400 2010:
> On Tue, Jul 27, 2010 at 04:13:56PM -0400, Alvaro Herrera wrote:
> > Excerpts from Kenichiro Tanaka's message of dom jul 25 21:01:01 -0400 2010:
> >
> > > This is a bug report.
> > > When I tested in PostgreSQL9 beta3,I got an error.
> > >
> > > ==================================================
> > > select * from part_bug where HIRENUM=4 for update;
> > > failed to fetch tuple for EvalPlanQual recheck
> > > ==================================================
> > >
> > > Is this error assumed?
> > Hmm, I don't see just an error message here, but an assertion failure:
> I guess youve compiled with --enable-cassert and Kenchiro-san has not?

Eh, of course. I'm just pointing out that this is a serious bug :-)
I spent some time looking at the code, but the EvalPlanQual stuff is
over my head. I imagine this is somehow related to the ItemIdSetInvalid
call in ExecLockRows line 97 ('cause that has to do with inheritance
too), but I can't tell.

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Andres Freund's message of mar jul 27 17:20:37 -0400 2010:
>> I guess youve compiled with --enable-cassert and Kenchiro-san has not?

> Eh, of course. I'm just pointing out that this is a serious bug :-)
> I spent some time looking at the code, but the EvalPlanQual stuff is
> over my head. I imagine this is somehow related to the ItemIdSetInvalid
> call in ExecLockRows line 97 ('cause that has to do with inheritance
> too), but I can't tell.

It's probably my fault --- all that code got rewritten in preparation
for refactoring ModifyTable out of execMain.c. Will look at it soon.

regards, tom lane

Kenichiro Tanaka <ketanaka(at)ashisuto(dot)co(dot)jp> writes:
> When I tested in PostgreSQL9 beta3,I got an error.

> ==================================================
> select * from part_bug where HIRENUM=4 for update;
> failed to fetch tuple for EvalPlanQual recheck
> ==================================================

This seems to be a simple oversight in the new EvalPlanQual logic ---
one place forgot to consider the possibility of inactive child tables.
I've committed a patch. Thanks for the report!

regards, tom lane

Hello.

I tried the test in PostgreSQL9.0 beta4.
And it never reproduces the EvalPlanQual recheck error!

Thank you for all reply!!

>> When I tested in PostgreSQL9 beta3,I got an error.
>>
>
>> ==================================================
>> select * from part_bug where HIRENUM=4 for update;
>> failed to fetch tuple for EvalPlanQual recheck
>> ==================================================
>>
> This seems to be a simple oversight in the new EvalPlanQual logic ---
> one place forgot to consider the possibility of inactive child tables.
> I've committed a patch. Thanks for the report!
>
> regards, tom lane
>
>