Re: New vacuum option to do only freezing

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New vacuum option to do only freezing
Date: 2019-01-18 20:07:50
Message-ID: CA+TgmoYSZCe-4nQkxThXcwC9GbVj9SrfwaSEEJD_Eqpc9AgEmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 17, 2019 at 1:57 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2019-01-18 20:15:23 Re: Using Btree to Provide Sorting on Suffix Keys with LIMIT
Previous Message Robert Haas 2019-01-18 20:05:02 Re: pgsql: Restrict the use of temporary namespace in two-phase transaction