7.1.1 backend crashes on updates to very large text columns

From: "Norman J(dot) Clarke" <norman(at)combimatrix(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: 7.1.1 backend crashes on updates to very large text columns
Date: 2001-05-28 15:24:29
Message-ID: Pine.LNX.4.21.0105280823580.7972-100000@norman-comp.combimatrix.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello,

I have some tables with text (TOAST) columns that store xml files of up to
about 100k in size. Most are less than 1-10k, with the 100k columns being
somewhat unusual. I'd like to have the liberty of occaisonally storing up
to about 2MB in these columns without resorting to BLOB columns if
possible.

However, on update to the larger (100k+)columns, the postgres backend
crashes and dumps core. I've included a backtrace from the core file. Does
anyone have an idea as to what might be happening? I'd appreciate any
insight the list could offer.

Some extra background: I am running PostgreSQL 7.1.1 on both Debian Linux
(potato) and Red Hat 6.2 with the same problem evident. The Red Hat
machine is a Pentium III 1GHz with 256MB RAM. The Debian machine is a dual
PIII 766 with 256MB RAM. I've included the backtrace in the message after
my signature.

Thanks!

Norman Clarke

--------------------------------------
Norman Clarke
Combimatrix Corp Software Development
Harbour Pointe Tech Center
6500 Harbour Heights Pkwy, Suite 301
Mukilteo, WA 98275

tel: 425.493.2240
fax: 425.493.2010
--------------------------------------

Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-linux-gnu"...
Core was generated by `postgres: deepak cbmx 192.168.1.51 UPDATE
'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libreadline.so.4...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libncurses.so.5...done.
Reading symbols from /lib/libnss_compat.so.2...done.
Reading symbols from /usr/local/pgsql/lib/plpgsql.so...done.
Reading symbols from /usr/local/pgsql/lib/contrib/pgcrypto.so...done.
#0 SPI_gettypeid (tupdesc=0x0, fnumber=1) at spi.c:501
501 if (tupdesc->natts < fnumber || fnumber <= 0)
(gdb) bt
#0 SPI_gettypeid (tupdesc=0x0, fnumber=1) at spi.c:501
#1 0x403745f5 in exec_move_row (estate=0xbfffef28, rec=0x0,
row=0x821dfc8, tup=0x0, tupdesc=0x0) at pl_exec.c:2640
#2 0x40372f1c in exec_stmt_select (estate=0xbfffef28, stmt=0x821e0b8) at
pl_exec.c:1455
#3 0x40372742 in exec_stmt (estate=0xbfffef28, stmt=0x821e0b8) at
pl_exec.c:978
#4 0x40372615 in exec_stmts (estate=0xbfffef28, stmts=0x821dea0) at
pl_exec.c:920
#5 0x40372568 in exec_stmt_block (estate=0xbfffef28, block=0x8218ea8) at
pl_exec.c:876
#6 0x403722eb in plpgsql_exec_trigger (func=0x821b158,
trigdata=0xbffff060) at pl_exec.c:738
#7 0x4036f966 in plpgsql_call_handler (fcinfo=0xbfffefb8) at
pl_handler.c:125
#8 0x80b8b5c in ExecCallTriggerFunc (trigger=0x40347fa4,
trigdata=0xbffff060, per_tuple_context=0x81ef060)
at trigger.c:865
#9 0x80b8e6e in ExecBRUpdateTriggers (estate=0x82181e0,
tupleid=0xbffff120, newtuple=0x82d1d18) at trigger.c:1008
#10 0x80bf7d1 in ExecReplace (slot=0x82184e0, tupleid=0xbffff120,
estate=0x82181e0) at execMain.c:1416
#11 0x80bf541 in ExecutePlan (estate=0x82181e0, plan=0x8218140,
operation=CMD_UPDATE, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x8230a98) at
execMain.c:1127
#12 0x80be9b7 in ExecutorRun (queryDesc=0x82181c8, estate=0x82181e0,
feature=3, count=0) at execMain.c:233
#13 0x810555b in ProcessQuery (parsetree=0x820c668, plan=0x8218140,
dest=Remote) at pquery.c:295
#14 0x8103f81 in pg_exec_query_string (
query_string=0x40392020 "UPDATE files SET ftype = 'exp', data
= '#", ' ' <repeats 19 times>, "THE WEBLOGIC PROPERTIES FILE\n# # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # #\n# This file,
which conforms to the java.uti"...,
dest=Remote, parse_context=0x81ee980) at postgres.c:810
#15 0x8105014 in PostgresMain (argc=5, argv=0xbffff3d8, real_argc=3,
real_argv=0xbffffd4c, username=0x81dc409 "deepak")
at postgres.c:1908
#16 0x80efc14 in DoBackend (port=0x81dc1a0) at postmaster.c:2114
#17 0x80ef7cc in BackendStartup (port=0x81dc1a0) at postmaster.c:1897
#18 0x80ee9f9 in ServerLoop () at postmaster.c:995
#19 0x80ee3e3 in PostmasterMain (argc=3, argv=0xbffffd4c) at
postmaster.c:685
#20 0x80ceaad in main (argc=3, argv=0xbffffd4c) at main.c:171

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Denis Gasparin 2001-05-28 15:38:58 Kylix, dbexpress & PostgreSql
Previous Message Dave Cramer 2001-05-28 15:21:26 Re: question