Re: Segmentation fault in 7.3 while vacuuming

> Frank van Vugt <ftm.van.vugt@foxi.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 "¿Ìëÿ¿@§\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.