Re: autovacuum not prioritising for-wraparound tables
От | Tom Lane |
---|---|
Тема | Re: autovacuum not prioritising for-wraparound tables |
Дата | |
Msg-id | 28562.1359071306@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: autovacuum not prioritising for-wraparound tables (Christopher Browne <cbbrowne@gmail.com>) |
Ответы |
Re: autovacuum not prioritising for-wraparound tables
|
Список | pgsql-hackers |
Christopher Browne <cbbrowne@gmail.com> writes: > On Thu, Jan 24, 2013 at 5:22 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> Backpatching sounds a bit scary. It's not a clear-cut bug, it's just that >> autovacuum could be smarter about its priorities. There are other ways you >> can still bump into the xid-wraparound issue, even with this patch. > I don't think this is a single-priority issue. It's *also* crucial > that small tables with high "tuple attrition rates" get vacuumed > extremely frequently; your system will bog down, albeit in a different > way, if the small tables don't get vacuumed enough. Yeah. Another problem with a simple-minded priority arrangement is that it might cause some tables to get starved for service because workers keep on choosing other ones; we have to be sure the sorting rule is designed to prevent that. As posted, what we've got here is sorting on a boolean condition, with the behavior within each group totally up to the whims of qsort(). That seems especially dangerous since the priority order is mostly undefined. I was a bit surprised that Alvaro didn't propose sorting by the age of relfrozenxid, at least for the subset of tables that are considered wraparound hazards. Not sure what a good criterion is for the rest. regards, tom lane
В списке pgsql-hackers по дате отправления: