On Fri, Jan 15, 2010 at 7:45 AM, Tom Lane <tgl@sss.pgh.pa.us> 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.
>
> 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.