Thread: core dump on 8.1 and no dump on REL8_1_STABLE
Hi! Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and HEAD. Am I missed some fixes/commits? PS dump in KOI8, db should be initialized as initdb -E KOI8-R --locale ru_RU.KOI8-R -D $DIR and it should be installed ltree and tsearch2 modules. PPS gdb output: Program received signal SIGSEGV, Segmentation fault. 0xb70f3f55 in crc32_sz (buf=0x1c4fabe1 <Address 0x1c4fabe1 out of bounds>, size=1282) at crc32.c:101 101 _CRC32_(crc, *p); (gdb) bt #0 0xb70f3f55 in crc32_sz (buf=0x1c4fabe1 <Address 0x1c4fabe1 out of bounds>, size=1282) at crc32.c:101 #1 0xb70f5f9d in gtsvector_compress (fcinfo=0xffffffff) at gistidx.c:161 #2 0x0821e8fd in FunctionCall1 (flinfo=0xffffffff, arg1=16777215) at fmgr.c:1128 #3 0x0807f752 in gistcentryinit (giststate=0xffffffff, nkey=0, e=0xbfdfb0c4, k=4294967295, r=0x0, pg=0x0, o=0, b=-1, l=1 '\001', isNull=0 '\0') at gistutil.c:731 #4 0x0807f0e0 in gistinsert (fcinfo=0xffffffff) at gist.c:255 #5 0x0821ecbe in FunctionCall6 (flinfo=0xffffff, arg1=4294967295, arg2=4294967295, arg3=4294967295, arg4=4294967295, arg5=4294967295, arg6=4294967295) at fmgr.c:1267 #6 0x08091d1a in index_insert (indexRelation=0xb7121620, values=0xbfdfb39c, isnull=0xbfdfb41c "", heap_t_ctid=0x837781c, heapRelation=0xb7172ab8, check_uniqueness=0 '\0') at indexam.c:215 #7 0x08131f23 in ExecInsertIndexTuples (slot=0x8373900, tupleid=0x837781c, estate=0x8373530, is_vacuum=0 '\0') at execUtils.c:936 #8 0x0812ac67 in ExecutorRun (queryDesc=0x8373150, direction=ForwardScanDirection, count=0) at execMain.c:1695 #9 0x081ab6a1 in ProcessQuery (parsetree=Variable "parsetree" is not available. ) at pquery.c:174 #10 0x081acb6a in PortalRun (portal=0x8370f78, count=2147483647, dest=0x82c517c, altdest=0x82c517c, completionTag=0xbfdfb688 "") at pquery.c:1076 #11 0x081a892f in exec_simple_query ( query_string=0x83591f8 "UPDATE \"Предприятия\" SET \"rubriks\"='\\'11\\' \\'17\\' \\'116\\' \\'135\\' \\'253\\' \\'303\\' \\'409\\' \\'415\\' \\'772\\' \\'1276\\' \\'1283\\' \\'1284\\' \\'1438\\' \\'1456\\'' WHERE \"id\"='66.20815';\n") at postgres.c:1014 #12 0x081aa230 in PostgresMain (argc=1, argv=0x8307248, username=0x83094a8 "postgres") at postgres.c:3168 #13 0x08148fb4 in main (argc=6, argv=0x8307248) at main.c:322 -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
Attachment
Teodor Sigaev <teodor@sigaev.ru> writes: > Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and HEAD. > Am I missed some fixes/commits? In HEAD I get \i tsearch2.sql ... \i ltree.sql ... \i tsearch2_crash.dump CREATE TABLE ALTER TABLE psql:tsearch2_crash.dump:86: ERROR: syntax error at position 0 near "�" CONTEXT: COPY �����������, line 1, column name_ltree: "�.�.�.�.�.�.�.�.�.�.�.�.�.�" psql:tsearch2_crash.dump:96: NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "�����������_pkey" for table "�����������" ALTER TABLE CREATE INDEX REVOKE REVOKE GRANT GRANT UPDATE 0 The "syntax error" doesn't seem very promising --- maybe this dump needs a particular locale/encoding setting to work (or fail as the case may be)? regards, tom lane
On Wed, 23 Nov 2005, Tom Lane wrote: > Teodor Sigaev <teodor@sigaev.ru> writes: >> Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and HEAD. >> Am I missed some fixes/commits? > > In HEAD I get > > \i tsearch2.sql > ... > \i ltree.sql > ... > \i tsearch2_crash.dump > CREATE TABLE > ALTER TABLE > psql:tsearch2_crash.dump:86: ERROR: syntax error at position 0 near "Й" > CONTEXT: COPY чьИАеьХНЕХН, line 1, column name_ltree: "Й.Ф.Е.Э.Й.М.А.Х.Э.Ш.И.Ж.Е.ь" > psql:tsearch2_crash.dump:96: NOTICE: ALTER TABLE / ADD PRIMARY KEY will create > implicit index "чьИАеьХНЕХН_pkey" for table "чьИАеьХНЕХН" > ALTER TABLE > CREATE INDEX > REVOKE > REVOKE > GRANT > GRANT > UPDATE 0 > > The "syntax error" doesn't seem very promising --- maybe this dump needs > a particular locale/encoding setting to work (or fail as the case may > be)? yes, it works fine for KOI8. I just load this dump into HEAD. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
initdb -E KOI8-R --locale ru_RU.KOI8-R -D $DIR > In HEAD I get HEAD and REL8_1STABLE works fine, 8.1 release not (I don't test REL8_1_0, just take a source package) -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
I reproduced the problem by loading this dump to 8.1.0. I think that the problem is the same as this: http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php I saw heap_tuple_toast_attrs() overwrites a new tuple. And, backend crashed while executing ExecInsertIndexTuples(). The problem occurs by the table like the following structures.(1)The table has a varlena column.(2)The table has a columnwith check constraint after the varlena column.(3)The table has a indexed column after the column with check constraint. And, the problem occurs if a tuple for which TOAST is necessary is inserted or updated. Example: create table test_tbl ( varlena_col text, check_col text, index_col text, constraint test_tbl_chkcheck (check_col ~ '^[0-9]+$') ); create index test_tbl_idx on test_tbl(index_col); insert into test_tbl (varlena_col, check_col, index_col) values('A', '0', 'B'); update test_tbl set varlena_col = repeat('A', 2000) where index_col = 'B'; The backend will be crashed or wrong data will be registered to the index. If backend is not crashed, Index Scan might return the wrong result. explain select count(*) from test_tbl where index_col = 'B'; QUERY PLAN ---------------------------------------------------------------------------Aggregate (cost=8.50..8.51 rows=1 width=0) -> Bitmap Heap Scan on test_tbl (cost=2.01..8.49 rows=3 width=0) Recheck Cond: (index_col = 'B'::text) -> Bitmap Index Scan on test_tbl_idx (cost=0.00..2.01 rows=3 width=0) Index Cond: (index_col = 'B'::text) select count(*) from test_tbl where index_col = 'B';count ------- 0 (Wrong result. Correct result is 1.) --- Atsushi Ogawa
Atsushi Ogawa <atsushi.ogawa@gmail.com> writes: > I reproduced the problem by loading this dump to 8.1.0. > I think that the problem is the same as this: > http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php Good catch --- I agree that bug probably explains it. regards, tom lane