Thread: 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!! >> 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 > >