Bug in 6.4 query of table in varchar.c

From: Marcus Mascari <mascarim(at)yahoo(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Bug in 6.4 query of table in varchar.c
Date: 1998-12-02 00:15:38
Message-ID: 19981202001538.20127.rocketmail@send103.yahoomail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

I have encountered a bug in 6.4 which reveals itself
in the following query:

Query:

SELECT supply, description, quantity, supplyunit, company||costcntr,
target, saledate,
price, 'pad' FROM sales WHERE target IN
('13132','13042','13070','12989','13120','12972')
AND supply IN
('1300600','1400034','0210300','1600966','1132050',
'1305522','0135250',
'1300326','1301695','1302009','1305169','0216190',
'1600735') AND saletype
IN ('Requisition','Replentish','Transfer')
ORDER BY supply, target, saledate;

I recompiled the postmaster with -g to yeild the
following backtrace:

GDB Trace:

#0 varchareq (arg1=0x32f9 <Address 0x32f9 out of bounds>,
arg2=0x81dd558 "\013") at varchar.c:636
636 len1 = VARSIZE(arg1) - VARHDRSZ;

(gdb) bt

#0 varchareq (arg1=0x32f9 <Address 0x32f9 out of bounds>,
arg2=0x81dd558 "\013") at varchar.c:636
#1 0x80f7ad3 in fmgr_c (finfo=0x81e58a8, values=0xbfffcefc,
isNull=0xbfffcf87 "") at fmgr.c:104
#2 0x808c92d in ExecMakeFunctionResult (node=0x81dd4a8,
arguments=0x81e03a8, econtext=0x81e2fa0,
isNull=0xbfffcf87 "",
isDone=0xbfffcf4b
"\001l\b\b\003\036\b/\036\b\207\020\004\036\b/\036\bH0\036\b\210=\b\b\0
03\036\b/\036\b\207\206!\001") at execQual.c:826
#3 0x808c970 in ExecEvalOper (opClause=0x81e03e8, econtext=0x81e2fa0,
isNull=0xbfffcf87 "")
at execQual.c:888
#4 0x808cbb4 in ExecEvalExpr (expression=0x81e03e8,
econtext=0x81e2fa0, isNull=0xbfffcf87 "",
isDone=0xbfffcf86 "\001") at execQual.c:1219
#5 0x808cc3d in ExecQualClause (clause=0x81e03e8, econtext=0x81e2fa0)
at execQual.c:1281
#6 0x808cc71 in ExecQual (qual=0x81e0410, econtext=0x81e2fa0) at
execQual.c:1347
#7 0x80908d1 in IndexNext (node=0x81e0ed0) at nodeIndexscan.c:157
#8 0x808cf64 in ExecScan (node=0x81e0ed0, accessMtd=0x80907f8
<IndexNext>) at execScan.c:102
#9 0x809098c in ExecIndexScan (node=0x81e0ed0) at nodeIndexscan.c:211
#10 0x808bb16 in ExecProcNode (node=0x81e0ed0, parent=0x81e1aa0) at
execProcnode.c:271
#11 0x80fb22e in createfirstrun (node=0x81e1aa0) at psort.c:402
#12 0x80fb068 in initialrun (node=0x81e1aa0) at psort.c:293
#13 0x80faf47 in psort_begin (node=0x81e1aa0, nkeys=3, key=0x81e47a8)
at psort.c:155
#14 0x809213f in ExecSort (node=0x81e1aa0) at nodeSort.c:156
#15 0x808bb3a in ExecProcNode (node=0x81e1aa0, parent=0x81e1aa0) at
execProcnode.c:295
#16 0x808b34f in ExecutePlan (estate=0x81e1b50, plan=0x81e1aa0,
parseTree=0x81a32b0, operation=CMD_SELECT,
numberTuples=0, direction=ForwardScanDirection,
printfunc=0x8061bcc <printtup>) at execMain.c:733
#17 0x808af00 in ExecutorRun (queryDesc=0x81e1b28, estate=0x81e1b50,
feature=3, count=0) at execMain.c:236
#18 0x80d4f83 in ProcessQueryDesc (queryDesc=0x81e1b28) at pquery.c:333
#19 0x80d4fe2 in ProcessQuery (parsetree=0x81a32b0, plan=0x81e1aa0,
dest=Remote) at pquery.c:376
#20 0x80d3ad4 in pg_exec_query_dest (
query_string=0xbfffd20c "SELECT supply, description, quantity,
supplyunit, company||costcntr, target, sal
edate,\nprice, 'pad' FROM sales WHERE target IN
('13132','13042','13070','12989','13120','12972')\nAND supply
IN ('1300600"..., dest=Remote, aclOverride=0) at postgres.c:800
#21 0x80d39cb in pg_exec_query (
query_string=0xbfffd20c "SELECT supply, description, quantity,
supplyunit, company||costcntr, target, sal
edate,\nprice, 'pad' FROM sales WHERE target IN
('13132','13042','13070','12989','13120','12972')\nAND supply
IN ('1300600"...) at postgres.c:699
#22 0x80d49e8 in PostgresMain (argc=7, argv=0xbffff284, real_argc=5,
real_argv=0xbffffc28)
---Type <return> to continue, or q <return> to quit---
at postgres.c:1645
#23 0x80c0652 in DoBackend (port=0x8167900) at postmaster.c:1528
#24 0x80c01a9 in BackendStartup (port=0x8167900) at postmaster.c:1299
#25 0x80bf921 in ServerLoop () at postmaster.c:757
#26 0x80bf500 in PostmasterMain (argc=5, argv=0xbffffc28) at
postmaster.c:563
#27 0x8099b54 in main (argc=5, argv=0xbffffc28) at main.c:93

The sales table is a table with ~250K rows and is
defined as follows:

Sales Table:

Table = sales
supplysource int4 not null
supply varchar(16) not null
supplyunit varchar(2) not null
quantity float8 not null
target int4 not null
company varchar(8) not null
costcntr varchar(8) not null
saletype varchar(16) not null
saledate datetime not null
price float8 not null
vendorname varchar(32) not null
vendor varchar(16) not null
vendorgroup varchar(16)
description varchar(64) not null

Indices: k_sales1
k_sales2
k_sales3
k_sales4

This bug is reproducable and occurred after I added
the description column to the sales table.

Thanks for any help,

Marcus Mascari (mascarim(at)yahoo(dot)com)

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-12-02 01:09:48 Re: [HACKERS] New platform-specific FAQ for HPUX
Previous Message Bruce Momjian 1998-12-01 23:27:41 Re: [HACKERS] Re: Mysql 321 - Mysql 322 - msql