Re: New vacuum option to do only freezing

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "Bossart, Nathan" <bossartn@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-01-21T10:20:33Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Add toast-level reloption for vacuum_index_cleanup

  2. heap_prepare_freeze_tuple: Simplify coding

  3. Fix missing word.

  4. Allow VACUUM to be run with index cleanup disabled.

  5. Don't mark pages all-visible spuriously