Re: autovacuum next steps, take 2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: autovacuum next steps, take 2
Date
Msg-id 10180.1172546800@sss.pgh.pa.us
Whole thread Raw
In response to Re: autovacuum next steps, take 2  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: autovacuum next steps, take 2  ("Matthew T. O'Connor" <matthew@zeut.net>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> I think an absolute minimum requirement for a sane design is that no two
>> workers ever try to vacuum the same table concurrently,

> FWIW, I've always considered this to be a very important and obvious
> issue, and I think I've neglected mentioning it (maybe I did too few
> times).  But I think this is pretty easy to do, just have each worker
> advertise the current table it's working on in shared memory, and add a
> recheck loop on the table-pick algorithm (with appropriate grabs of the
> autovacuum lwlock), to make sure no one starts to vacuum the same table
> you're going to process, at the same time.

Well, any of these proposals need that at the bottom level, to prevent
race conditions.  But I'd prefer a design that wasn't positively
encouraging multiple workers to try to pick the same table concurrently.
Not only is that wasteful, but it makes it harder to predict what is the
real behavior that emerges after race conditions are backed off from.

BTW, to what extent might this whole problem be simplified if we adopt
chunk-at-a-time vacuuming (compare current discussion with Galy Lee)?
If the unit of work has a reasonable upper bound regardless of table
size, maybe the problem of big tables starving small ones goes away.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: autovacuum next steps, take 2
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: autovacuum next steps, take 2