Re: Segmentation fault in 7.3 while vacuuming

> Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> writes:
> > Is this known behaviour?
>
TL> Nope.
>
> > Otherwise, I'd be glad to assist with a backtrace.
>
TL> Please.

** PostgreSQL v7.3 configured with:
./configure --prefix=/usr/src/postgresql_debug/pgsql --enable-debug
--with-openssl --with-perl --with-python --with-tcl --with-pgport=5433

** while using a client written in TrollTech's QT v3.1 that creates a number
of temporary tables, uses a number lot of 'copy' statements and at the end
tries to 'vacuum full analyse' the database

** the backend crashes.... ;(

** last information received by the frontend:
INFO: --Relation pg_temp_2.t_article_details--
Warning: QSqlDatabaseManager unable to open database: FATAL: The database
system is in recovery mode

** backend's log:
LOG: query: update stock_pick set amount = case when pallet_amount >
amount_stock then amount_stock else pallet_amount end from
t_stock where stock_pick.article_id = t_stock.id
LOG: recycled transaction log file 0000000000000017
LOG: query: update t_stock set amount_stock = case when pallet_amount >
amount_stock then 0 else amount_stock - pallet_amount end where
exists (select 1 from stock_pick where article_id = t_stock.id)
LOG: query: insert into stock_bulk select 5, id, amount_stock, 0, 1, false,
null from t_stock
LOG: query: SELECT 1 FROM ONLY "public"."location" x WHERE "id" = $1 FOR
UPDATE OF x
LOG: query: SELECT 1 FROM ONLY "public"."article" x WHERE "id" = $1 FOR
UPDATE OF x
LOG: query: SELECT 1 FROM ONLY "public"."pallet_type" x WHERE "id" = $1 FOR
UPDATE OF x
LOG: query: truncate table t_stock
LOG: query: drop table aux_country, aux_language, aux_purchaser,
aux_salesperson, aux_valuta, aux_address
LOG: query: drop index temp01, temp02, temp03
LOG: query: vacuum full verbose analyse
LOG: recycled transaction log file 000000000000001A
LOG: recycled transaction log file 0000000000000018
LOG: recycled transaction log file 0000000000000019
LOG: server process (pid 32663) was terminated by signal 11
LOG: terminating any other active server processes
WARNING: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
LOG: connection received: host=192.168.0.79 port=33762
FATAL: The database system is in recovery mode
LOG: all server processes terminated; reinitializing shared memory and
semaphores
LOG: database system was interrupted at 2002-12-05 12:22:50 CET
LOG: checkpoint record is at 0/1DAEA234
LOG: redo record is at 0/1D8D2C10; undo record is at 0/0; shutdown FALSE
LOG: next transaction id: 5145; next oid: 451153
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: redo starts at 0/1D8D2C10
LOG: ReadRecord: record with zero length at 0/1DB74550
LOG: redo done at 0/1DB7452C
LOG: recycled transaction log file 000000000000001B
LOG: recycled transaction log file 000000000000001C
LOG: database system is ready

** backtrace of the coredump:
#0 _mdfd_getrelnfd (reln=0x0) at md.c:854
854 fd = RelationGetFile(reln);
(gdb) bt
#0 _mdfd_getrelnfd (reln=0x0) at md.c:854
#1 0x8123a0f in _mdfd_getseg (reln=0x0, blkno=13) at md.c:878
#2 0x812349d in mdwrite (reln=0x0, blocknum=13, buffer=0x848dde8 "") at
md.c:461
#3 0x8123e31 in smgrwrite (which=0, reln=0x0, blocknum=13, buffer=0x848dde8
"") at smgr.c:328
#4 0x811be2a in LocalBufferAlloc (reln=0x413979d0, blockNum=0,
foundPtr=0xbfffebb7 "¿Ìëÿ¿(at)§\021\bÐy9A") at localbuf.c:100
#5 0x811a7c2 in ReadBufferInternal (reln=0x413979d0, blockNum=0,
bufferLockHeld=0 '\000') at bufmgr.c:144
#6 0x811a740 in ReadBuffer (reln=0x413979d0, blockNum=0) at bufmgr.c:112
#7 0x80d7d19 in scan_heap (vacrelstats=0x8389430, onerel=0x413979d0,
vacuum_pages=0xbfffed50, fraged_pages=0xbfffed40) at vacuum.c:1069
#8 0x80d7a79 in full_vacuum_rel (onerel=0x413979d0, vacstmt=0x8313858) at
vacuum.c:910
#9 0x80d799e in vacuum_rel (relid=374498, vacstmt=0x8313858,
expected_relkind=114 'r') at vacuum.c:827
#10 0x80d73a3 in vacuum (vacstmt=0x8313858) at vacuum.c:290
#11 0x8126ff6 in ProcessUtility (parsetree=0x8313858, dest=Remote,
completionTag=0xbfffee30 "") at utility.c:713
#12 0x8124dcc in pg_exec_query_string (query_string=0x8313688, dest=Remote,
parse_context=0x82ddb70) at postgres.c:789
#13 0x8125df7 in PostgresMain (argc=4, argv=0xbffff058, username=0x82d4a81
"postgres") at postgres.c:2016
#14 0x810eab9 in DoBackend (port=0x82d4950) at postmaster.c:2293
#15 0x810e467 in BackendStartup (port=0x82d4950) at postmaster.c:1915
#16 0x810d7d4 in ServerLoop () at postmaster.c:1018
#17 0x810d331 in PostmasterMain (argc=4, argv=0x82bce00) at postmaster.c:779
#18 0x80ee909 in main (argc=4, argv=0xbffff974) at main.c:210
#19 0x400d4577 in __libc_start_main () from /lib/libc.so.6
(gdb)

If you need more details on machine/tables/etc. just let me know.
-> the backend doesn't crash if the vacuum is done through psql AFTER the
clients work is done (and the temporary tables are automatically destroyed)

Regards,

Frank.