Re: New vacuum option to do only freezing
От | Masahiko Sawada |
---|---|
Тема | Re: New vacuum option to do only freezing |
Дата | |
Msg-id | CAD21AoBJBj1Mx3ZFp-wkzRN7pJ6hfa-YykDAZTgCyQS5JrF4Jg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New vacuum option to do only freezing (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: New vacuum option to do only freezing
|
Список | pgsql-hackers |
On Sat, Jan 19, 2019 at 5:08 AM Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Jan 17, 2019 at 1:57 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > The reason why I processed the tuples that became dead after the first > > heap pass is that I was not sure the reason why we ignore such tuples > > in the second heap pass despite of there already have been the code > > doing so which has been used for a long time. I thought we can do that > > in the same manner even in DISABLE_INDEX_CLEANUP case. Also, since I > > thought that lazy_vacuum_page() is the best place to set them as DEAD > > I modified it (In the previous patch I introduced another function > > setting them as DEAD aside from lazy_vacuum_page(). But since these > > were almost same I merged them). > > The race you're concerned about is extremely narrow. We HOT-prune the > page, and then immediately afterward -- probably a few milliseconds > later -- we loop over the tuples still on the page and check the > status of each one. The only time we get a different answer is when a > transaction aborts in those few milliseconds. We don't worry about > handling those because it's a very rare condition. > Understood and Agreed. I've attached the new version patch incorporated the review comments. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: