Cursor bug - Mailing list pgsql-bugs
From | Mincu Alexandru |
---|---|
Subject | Cursor bug |
Date | |
Msg-id | 1062525075.9774.11.camel@tintagel.bucharest.cyberembryonic.com Whole thread Raw |
Responses |
Re: Cursor bug
|
List | pgsql-bugs |
Your name : Mincu Alexandru Your email address : alex@cyberembryonic.com System Configuration --------------------- Architecture (example: Intel Pentium) : AMD Duron(tm) Processor Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.20-20.9 ELF PostgreSQL version (example: PostgreSQL-7.3.4): PostgreSQL-7.3.4 Compiler used (example: gcc 2.95.2) : gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) FULL description of problem: ------------------------------------------------ server segfaults when trying to move backward in a cursor. This only happens if I run VACCUM ANALYZE on the database first. Way to repeat the problem: ---------------------------------------------------------------------- alex@tintagel:~$ psql tst Welcome to psql 7.3.4, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit tst=# begin; BEGIN tst=# declare "cursor1" cursor for select * from test left join test2 on (test2.foo1=test.foo_id) left join test3 on (test3.foo2=test2.foo_id); DECLARE CURSOR tst=# fetch all from cursor1; foo_id | foo1 | foo2 | foo3 | foo_id | foo1 | foo2 | foo3 | foo_id | foo2 | foo1 | foo3 --------+------+------+------+--------+------+------+------+--------+------+------+------ 1 | hhh | ggg | 333 | 1 | 1 | bau | tst | 3 | 1 | bau | tst 2 | tra | bau | tst | 2 | 2 | ggg | 333 | 4 | 2 | ggg | 333 3 | hhh | ggg | 333 | 3 | 3 | bau | tst | 5 | 3 | bau | tst 4 | tra | bau | tst | 4 | 4 | ggg | 333 | 6 | 4 | ggg | 333 5 | hhh | ggg | 333 | 5 | 5 | bau | tst | 1 | 5 | bau | tst 6 | tra | bau | tst | 6 | 6 | ggg | 333 | 2 | 6 | ggg | 333 7 | hhh | ggg | 333 | | | | | | | | 8 | tra | bau | tst | | | | | | | | 9 | hhh | ggg | 333 | | | | | | | | 10 | tra | bau | tst | | | | | | | | 11 | hhh | ggg | 333 | | | | | | | | 12 | tra | bau | tst | | | | | | | | (12 rows) tst=# move backward 0 in cursor1; MOVE 12 tst=# close cursor1; CLOSE CURSOR tst=# rollback; ROLLBACK tst=# VACUUM ANALYZE ; VACUUM tst=# BEGIN ; BEGIN tst=# declare "cursor1" cursor for select * from test left join test2 on (test2.foo1=test.foo_id) left join test3 on (test3.foo2=test2.foo_id); DECLARE CURSOR tst=# fetch all from cursor1; foo_id | foo1 | foo2 | foo3 | foo_id | foo1 | foo2 | foo3 | foo_id | foo2 | foo1 | foo3 --------+------+------+------+--------+------+------+------+--------+------+------+------ 1 | hhh | ggg | 333 | 1 | 1 | bau | tst | 3 | 1 | bau | tst 2 | tra | bau | tst | 2 | 2 | ggg | 333 | 4 | 2 | ggg | 333 3 | hhh | ggg | 333 | 3 | 3 | bau | tst | 5 | 3 | bau | tst 4 | tra | bau | tst | 4 | 4 | ggg | 333 | 6 | 4 | ggg | 333 5 | hhh | ggg | 333 | 5 | 5 | bau | tst | 1 | 5 | bau | tst 6 | tra | bau | tst | 6 | 6 | ggg | 333 | 2 | 6 | ggg | 333 7 | hhh | ggg | 333 | | | | | | | | 8 | tra | bau | tst | | | | | | | | 9 | hhh | ggg | 333 | | | | | | | | 10 | tra | bau | tst | | | | | | | | 11 | hhh | ggg | 333 | | | | | | | | 12 | tra | bau | tst | | | | | | | | (12 rows) tst=# move backward 0 in cursor1; 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. !# Backtrace: (gdb) cont Continuing. Program received signal SIGABRT, Aborted. 0xffffe002 in ?? () (gdb) bt #0 0xffffe002 in ?? () #1 0x42028b93 in abort () from /lib/tls/libc.so.6 #2 0x081b187b in ExceptionalCondition (conditionName=0x6 <Address 0x6 out of bounds>, errorType=0x81c73de "FailedAssertion", fileName=0x42131a14 "\031\023B@G#@`?", lineNumber=0) at assert.c:46 #3 0x080f9508 in ExecEvalVar (variable=0x6, econtext=0x42131a14, isNull=0xbfffe19f "") at execQual.c:383 #4 0x080fada3 in ExecEvalExpr (expression=0x8330eb4, econtext=0x8332728, isNull=0x6 <Address 0x6 out of bounds>, isDone=0x42131a14) at execQual.c:1682 #5 0x080fb1bf in ExecTargetList (targetlist=0x8330ee0, nodomains=8, targettype=0x83331e0, values=0x833365c, econtext=0x8332728, isDone=0xbfffe3ac) at execQual.c:2058 #6 0x080fb4dc in ExecProject (projInfo=0x42131a14, isDone=0x0) at execQual.c:2282 #7 0x08101b65 in ExecMergeJoin (node=0x8330dc0) at nodeMergejoin.c:1345 #8 0x080f8b03 in ExecProcNode (node=0x8330dc0, parent=0x0) at execProcnode.c:318 #9 0x08101f40 in ExecNestLoop (node=0x83303a4) at nodeNestloop.c:128 #10 0x080f8af9 in ExecProcNode (node=0x83303a4, parent=0x0) at execProcnode.c:314 #11 0x080f74c5 in ExecutePlan (estate=0x8332384, plan=0x83303a4, operation=CMD_SELECT, numberTuples=0, direction=NoMovementScanDirection, destfunc=0x8250f00) at execMain.c:955 #12 0x080f687c in ExecutorRun (queryDesc=0x0, estate=0x8332384, direction=BackwardScanDirection, count=0) at execMain.c:195 #13 0x080dd371 in PerformPortalFetch (name=0x83339f8 "\001", forward=0 '\0', count=0, dest=None, completionTag=0xbfffe5e0 "MOVE 0") at portalcmds.c:165 #14 0x0815c561 in ProcessUtility (parsetree=0x83166f8, dest=None, completionTag=0xbfffe5e0 "MOVE 0") at utility.c:269 #15 0x08159eab in pg_exec_query_string (query_string=0x83166f8, dest=Remote, parse_context=0x82e0bf0) at postgres.c:789 #16 0x0815afa9 in PostgresMain (argc=4, argv=0xbfffe840, username=0x82dbe59 "alex") at postgres.c:2013 #17 0x0813b02b in DoBackend (port=0x82dbd28) at postmaster.c:2310 #18 0x0813aab3 in BackendStartup (port=0x82dbd28) at postmaster.c:1932 #19 0x081398e6 in ServerLoop () at postmaster.c:1009 #20 0x0813902b in PostmasterMain (argc=3, argv=0x8290d00) at postmaster.c:788 #21 0x0810eeb3 in main (argc=3, argv=0xbffff1d4) at main.c:210 #22 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) frame 3 #3 0x080f9508 in ExecEvalVar (variable=0x6, econtext=0x42131a14, isNull=0xbfffe19f "") at execQual.c:383 383 return result; the sql dump of the database is attached If you know how this problem might be fixed, list the solution below: --------------------------------------------------------------------- donno' :( Regards, -- Mincu Alexandru <alex@cyberembryonic.com> Cyberembryonic.com
Attachment
pgsql-bugs by date: