Re: Unexpected VACUUM FULL failure
От | Tom Lane |
---|---|
Тема | Re: Unexpected VACUUM FULL failure |
Дата | |
Msg-id | 7670.1186710163@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Unexpected VACUUM FULL failure ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: Unexpected VACUUM FULL failure
|
Список | pgsql-hackers |
"Simon Riggs" <simon@2ndquadrant.com> writes: > Good hunch. I plugged this hole earlier, but on further inspection I can > see the plug wasn't wide enough. XLogAsyncCommitFlush() is good enough, > but HeapTupleSatisfiesVacuum() still allowed the inexact bookkeeping to > sometimes skip hint bit setting, when executed with concurrent > transactions touching other tables. > ISTM that if we call HeapTupleSatisfiesVacuum() with an additional > boolean parameter, force, we can tell VF to always set the hint bits in > every case, not just HEAP_MOVED_IN and HEAP_MOVED_OUT. Surely this approach is no good: won't it allow hint bits to reach disk in advance of their transaction? I think it'd be safer, and a lot less ugly, to recast the tests in VACUUM FULL. If we make the first pass clear any old MOVED_IN/MOVED_OUT bits then the last pass can key off those instead of assuming that XMIN_COMMITTED is set everywhere. Then we'd not need XLogAsyncCommitFlush, which is a kluge anyway. regards, tom lane
В списке pgsql-hackers по дате отправления: