On Fri, Jan 15, 2010 at 7:45 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Ben Chobot <bench@xxxxxxxxxxxxxxx> 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. > > Also ask on the slony lists if anyone's seen anything like this. I > don't know a reason for slony to have any effect like that, but there's > got to be *something* weird going on. I've seen a situation like there during ddl ops (using the slony execute command to run them on the cluster) where slony halts waiting on vacuum and everything else halts waiting on slony. That was with slony 1.2 With slony 2.0.3 or so, I had occasional complete lockups of my database that I didn't have time to troubleshoot as it was a live cluster and I had to restart slony and the databases to get them back up and running. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
