Re: VACUUM is hanging - Mailing list pgsql-general
From | Ashley Clark |
---|---|
Subject | Re: VACUUM is hanging |
Date | |
Msg-id | 20010504192514.A21401@ghoti.org Whole thread Raw |
In response to | Re: VACUUM is hanging (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: VACUUM is hanging
|
List | pgsql-general |
* Tom Lane in "Re: [GENERAL] VACUUM is hanging" dated 2001/05/04 11:09 * wrote: > It's unclear what the process doing the vacuum could be waiting for; > can you attach to it with gdb and get a backtrace? OK, here's the backtrace of the process listed in the log following: 2001-05-04 19:18:15 [6273] DEBUG: --Relation personnel-- 2001-05-04 19:18:15 [6273] DEBUG: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. 2001-05-04 19:18:15 [6273] DEBUG: Index personnel_pkey: Pages 1; Tuples 0. CPU 0.00s/0.00u sec. 2001-05-04 19:18:15 [6273] DEBUG: Index personnel_name: Pages 1; Tuples 0. CPU 0.00s/0.00u sec. 2001-05-04 19:18:15 [6273] DEBUG: Index personnel_truck: Pages 1; Tuples 0. CPU 0.00s/0.00u sec. 2001-05-04 19:18:15 [6273] DEBUG: Index personnel_ssn: Pages 1; Tuples 0. CPU 0.00s/0.00u sec. 2001-05-04 19:18:15 [6273] DEBUG: Analyzing... Backtrace: #0 0x402323db in semop () from /lib/libc.so.6 #1 0x80fe0c2 in IpcSemaphoreLock (semId=7425, sem=9, interruptOK=1 '\001') at ipc.c:426 #2 0x8102059 in ProcSleep (lockMethodTable=0x82ebf10, lockmode=7, lock=0x403d8860, holder=0x403d9768) at proc.c:666 #3 0x8101377 in WaitOnLock (lockmethod=1, lockmode=7, lock=0x403d8860, holder=0x403d9768) at lock.c:955 #4 0x8101139 in LockAcquire (lockmethod=1, locktag=0xbfffefb0, xid=16748, lockmode=7) at lock.c:739 #5 0x81005f4 in LockRelation (relation=0x4054a828, lockmode=7) at lmgr.c:141 #6 0x806fb4c in heap_open (relationId=19226, lockmode=7) at heapam.c:596 #7 0x80b1d6d in vacuum_rel (relid=19226) at vacuum.c:400 #8 0x80b1aba in vac_vacuum (VacRelP=0x0, analyze=1 '\001', anal_cols2=0x0) at vacuum.c:245 #9 0x80b1a2e in vacuum (vacrel=0x0, verbose=0, analyze=1 '\001', anal_cols=0x0) at vacuum.c:163 #10 0x8107ddc in ProcessUtility (parsetree=0x8329980, dest=Remote) at utility.c:708 #11 0x8105b5a in pg_exec_query_string ( query_string=0x83297f0 "vacuum analyze;", dest=Remote, parse_context=0x8303f68) at postgres.c:777 #12 0x8106c74 in PostgresMain (argc=4, argv=0xbffff380, real_argc=3, real_argv=0xbffffd44, username=0x82f97c9 "postgres") at postgres.c:1908 #13 0x80f1234 in DoBackend (port=0x82f9560) at postmaster.c:2111 #14 0x80f0df4 in BackendStartup (port=0x82f9560) at postmaster.c:1894 #15 0x80eff10 in ServerLoop () at postmaster.c:992 #16 0x80ef889 in PostmasterMain (argc=3, argv=0xbffffd44) at postmaster.c:682 #17 0x80d00f2 in main (argc=3, argv=0xbffffd44) at main.c:147 I also seem to have found the culprit. I have Apache::DBI set up and it's holding something open. Restarting Apache let the vacuum finish normally. Any suggestions as to how I can remedy this situation. I'd like to avoid having to stop/start Apache before/after the vacuum. -- creaky halls
Attachment
pgsql-general by date: