Ashley Clark <aclark@ghoti.org> writes:
> #5 0x81005f4 in LockRelation (relation=3D0x4054a828, lockmode=3D7) at lmgr=
> .c:141
> #6 0x806fb4c in heap_open (relationId=3D19226, lockmode=3D7) at heapam.c:5=
> 96
> #7 0x80b1d6d in vacuum_rel (relid=3D19226) at vacuum.c:400
> #8 0x80b1aba in vac_vacuum (VacRelP=3D0x0, analyze=3D1 '\001', anal_cols2=
> =3D0x0)
> at vacuum.c:245
> #9 0x80b1a2e in vacuum (vacrel=3D0x0, verbose=3D0, analyze=3D1 '\001',
> anal_cols=3D0x0) at vacuum.c:163
Looks like it's waiting to get an exclusive lock on the table it plans
to vacuum next (which is the one with OID 19226 in pg_class, if you want
to find out).
> 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.
Try not to leave open transactions hanging around in your Apache code.
An idle database connection couldn't block VACUUM like that; it'd have
to have been in the middle of a BEGIN block, or maybe even an unfinished
query.
regards, tom lane