Re: autovacuum next steps, take 2

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: autovacuum next steps, take 2
Дата
Msg-id 10180.1172546800@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: autovacuum next steps, take 2  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: autovacuum next steps, take 2  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список 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 по дате отправления:

Предыдущее
От: "Matthew T. O'Connor"
Дата:
Сообщение: Re: autovacuum next steps, take 2
Следующее
От: "Matthew T. O'Connor"
Дата:
Сообщение: Re: autovacuum next steps, take 2