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@commandprompt.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@ashisuto.co.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!!
Show quoted text
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