Bug in 6.4 query of table in varchar.c

Поиск
Список
Период
Сортировка
От Marcus Mascari
Тема Bug in 6.4 query of table in varchar.c
Дата
Msg-id 19981202001538.20127.rocketmail@send103.yahoomail.com
обсуждение исходный текст
Список 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 supplyIN ('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 supplyIN ('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@yahoo.com)









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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] 6.4.x
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] New platform-specific FAQ for HPUX