On Fri, 15 Jan 2010, Tom Lane wrote:
Ben Chobot <be...@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 ()
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
