On Fri, 15 Jan 2010, Tom Lane wrote:
> Ben Chobot <bench@silentmedia.com> writes:
>> We have recently discovered a problem with our slony-1 cluster of 8.1.19
>> installs. Specifically, we are unable to vacuum a table on the master
>> node; vacuum always hangs on the same index of the same table. If we do a
>> slony switchover and make the other node the master, then *it* will become
>> unable to vacuum that index. Vacuum on the slave always works quickly and
>> without issue. Vacuum does not hang anywhere else.
>
>> When we tried to strace the vacuuming backend, it appeared as if it was
>> trying to acquire a lock, but pg_lock showed nothing unexpected for that
>> index.
>
> Try attaching to the process with gdb and getting a stack trace.
#0 0x00007f59a5d78ca7 in semop () from /lib/libc.so.6
#1 0x0000000000546656 in PGSemaphoreLock ()
#2 0x00000000005618ee in LockBufferForCleanup ()
#3 0x000000000045c8e2 in btbulkdelete ()
#4 0x00000000005eb179 in FunctionCall3 ()
#5 0x00000000004ed81a in ?? ()
#6 0x00000000004ee132 in lazy_vacuum_rel ()
#7 0x00000000004ec0e4 in ?? ()
#8 0x00000000004ecdeb in vacuum ()
#9 0x0000000000577837 in ?? ()
#10 0x0000000000578da1 in PortalRun ()
#11 0x0000000000574b2b in ?? ()
#12 0x000000000057611e in PostgresMain ()
#13 0x000000000054e66b in ?? ()
#14 0x000000000054f5d1 in PostmasterMain ()
#15 0x00000000005128de in main ()
