Re: heap vacuum & cleanup locks
От | Simon Riggs |
---|---|
Тема | Re: heap vacuum & cleanup locks |
Дата | |
Msg-id | CA+U5nMK87iNG1nz54zKRzJvhpDn7eeWRia8fzYr_A6SO9JHhOg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: heap vacuum & cleanup locks (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: heap vacuum & cleanup locks
|
Список | pgsql-hackers |
On Fri, Nov 4, 2011 at 6:18 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Here's a new version. I fixed the second pass as discussed (which > turned out to be trivial). To address the concern about relpages, I > moved this pre-existing line to after we get the buffer lock: > > + vacrelstats->scanned_pages++; > > That appears to do the right thing. I think we need to count skipped pages also. I don't like the idea that vacuum would just report less pages than there are in the table. We'll just get requests to explain that. > I found it kind of confusing that lazy_scan_page_for_wraparound() > returns with the pin either held or not held depending on the return > value, so I rearranged things very slightly so that it doesn't need to > do that. I'm wondering whether we should rename that function to > something like lazy_check_needs_freeze(). OK > I tested this out and discovered that "VACUUM FREEZE" doesn't set the > for_wraparound flag. On further review, I think that we should > probably conditionalize the behavior on the scan_all flag that > lazy_vacuum_rel sets, rather than for_wraparound. Otherwise, there's > no way for the user to manually force relfrozenxid to advance, which > doesn't seem good. I haven't made that change in this version, > though. Agreed, separate patch. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: