Cursor bug

Your name : Mincu Alexandru
Your email address : alex(at)cyberembryonic(dot)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(at)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(at)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(at)cyberembryonic(dot)com>
Cyberembryonic.com