Claudio Freire <claudio@livra.com> writes:
> What I did do is analyze server load during the events, and as I
> suspected, disk activity during the "deadlocks" seems to suggest a
> vacuuming taking place. Although there was no autovacuum entry in
> pg_stat_activity every time I checked, disk activity precisely matches
> the case when autovacuum decides to vacuum a big table.
[ shrug... ] If autovacuum isn't shown in pg_stat_activity then it's
pretty hard to credit that there was an autovacuum going on. Moreover,
if there *was* an undetected deadlock that autovacuum was somehow
involved in, then the autovacuum would be blocked too so it's hardly
possible that you'd miss seeing it in pg_stat_activity.
> That's about as much information I can give. We've worked around the
> issue successfully and it hasn't happened since. Even if it is not a
> proper deadlock, the performance drop is unacceptable. I've done massive
> updates before, and that performance drop was not expected (more than
> one day for updating 30k rows on a table with a couple indices).
I'm afraid we're not going to be able to do much with this report
if you can't provide a reproduction scenario.
regards, tom lane
