[moving this from pg-general to slony1-general on the off chance it's more related to slony...]

On Jan 15, 2010, at 8:41 AM, Scott Marlowe wrote:

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

We're using slony 1.2.15, for what that's worth. I don't see anything in the 1.2.x release notes that would indicate any problem like this, but I'm new to slony.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20100115/e9669567/attachment.htm