On Sat, 2007-10-27 at 23:22 +0100, Simon Riggs wrote:
On Fri, 2007-10-26 at 10:32 +0100, Heikki Linnakangas wrote:
Alvaro Herrera wrote:
/*
* Look for a blocking autovacuum. There will only ever
* be one, since the autovacuum workers are careful
* not to operate concurrently on
On Thu, 2007-10-25 at 17:35 -0400, Tom Lane wrote:
There's some things still to be desired here: if an autovac process is
involved in a hard deadlock, the patch doesn't favor zapping it over
anybody else, nor consider cancelling the autovac as an alternative to
rearranging queues for a soft
On Fri, 2007-10-26 at 10:32 +0100, Heikki Linnakangas wrote:
Alvaro Herrera wrote:
/*
* Look for a blocking autovacuum. There will only ever
* be one, since the autovacuum workers are careful
* not to operate concurrently on the same table.
*/
I think that's a bit unaccurate.
On Fri, 2007-10-26 at 17:50 -0300, Alvaro Herrera wrote:
Ok, committed; I snuck that in as well, but I'm not sure how to test
that it works.
I've had time to review that now. I didn't reply to your original post
because you'd taken my name off the copy list for some reason and I've
been too
Tom Lane [EMAIL PROTECTED] writes:
I think there's a window where the process waiting directly on
autovacuum could have already fired its deadlock check before it was
waiting directly on autovacuum.
I think you don't understand what that code is doing. If there's an
autovac anywhere in
Alvaro Herrera wrote:
/*
* Look for a blocking autovacuum. There will only ever
* be one, since the autovacuum workers are careful
* not to operate concurrently on the same table.
*/
I think that's a bit unaccurate. You could have multiple autovacuum
workers operating on different
Heikki Linnakangas [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
/*
* Look for a blocking autovacuum. There will only ever
* be one, since the autovacuum workers are careful
* not to operate concurrently on the same table.
*/
I think that's a bit unaccurate. You could have multiple
Gregory Stark [EMAIL PROTECTED] writes:
I assume the right thing happens if multiple deadlock check signals fire for
the same autovacuum?
Multiple signals shouldn't be a problem, but late-arriving ones could be.
It might be worth having autovac explicitly clear QueryCancelPending
after it's
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
I assume the right thing happens if multiple deadlock check signals fire for
the same autovacuum?
Multiple signals shouldn't be a problem, but late-arriving ones could be.
It might be worth having autovac explicitly clear
Simon Riggs wrote:
Just noticed you've made these changes. I was working on them, but
hadn't fully tested the patch because of all the different touch points.
Sorry for the delay.
Would you like me to refresh my earlier patch against the newly
committed state (or did you commit that aspect
Alvaro Herrera [EMAIL PROTECTED] writes:
Patch attached, please comment. It only avoids cancelling when the
vacuum is for wraparound.
I'm not entirely convinced that there can be only one autovac proc in
the portion of the waits-for graph explored by DeadlockCheck. If there
is more than one,
Tom Lane [EMAIL PROTECTED] writes:
There's some things still to be desired here: if an autovac process is
involved in a hard deadlock, the patch doesn't favor zapping it over
anybody else, nor consider cancelling the autovac as an alternative to
rearranging queues for a soft deadlock. But
Gregory Stark [EMAIL PROTECTED] writes:
Can autovacuum actually get into a hard deadlock?
It can certainly be part of a deadlock loop, though the practical cases
might be few. It will be holding more than one lock, eg a lock on its
target table and various transient locks on system catalogs,
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
I think there's a window where the process waiting directly on
autovacuum could have already fired its deadlock check before it was
waiting directly on autovacuum.
I think you don't understand what that code is doing. If there's
14 matches
Mail list logo
