Re: VACUUM is hanging

From: Ashley Clark <aclark(at)ghoti(dot)org>
To: Postgres General List <pgsql-general(at)postgresql(dot)org>
Subject: Re: VACUUM is hanging
Date: 2001-05-05 00:25:14
Message-ID: 20010504192514.A21401@ghoti.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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, UnUsed 0, 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2001-05-05 00:28:03 Re: IpcMemoryCreate: shmget failed (Invalid argument)
Previous Message Frank Miles 2001-05-05 00:20:56 Re: Getting a list of fields in a table...