Re: Flaky vacuum truncate test in reloptions.sql - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Flaky vacuum truncate test in reloptions.sql
Date
Msg-id YGVL46GoetxG08LF@paquier.xyz
Whole thread Raw
In response to Re: Flaky vacuum truncate test in reloptions.sql  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Flaky vacuum truncate test in reloptions.sql  (Arseny Sher <a.sher@postgrespro.ru>)
List pgsql-hackers
On Thu, Apr 01, 2021 at 12:52:21PM +0900, Masahiko Sawada wrote:
> Just to be clear the context, I’m mentioning the following test case:

(Coming back a couple of emails later, where indeed I forgot about the
business with lazy_check_needs_freeze() that could cause a page to be
skipped even if DISABLE_PAGE_SKIPPING is used.)

> What I meant is that without FREEZE option, there are two possible
> cases where the table is not truncated (i.g.,
> pg_relation_size('reloptions_test') > 0 is true): the page got empty
> by vacuum but is not truncated because of vacuum_truncate = false, and
> the page could not be vacuumed (i.g., tuples remain in the page)
> because the page is skipped due to conflict on cleanup lock on the
> page. This test is intended to test the former case. I guess adding
> FREEZE will prevent the latter case.

What you are writing here makes sense to me.  Looking at the test, it
is designed to test vacuum_truncate, aka that the behavior we want to
stress (your former case here) gets stressed all the time, so adding
the options to avoid the latter case all the time is an improvement.
And this, even if the latter case does not actually cause a diff and
it has a small chance to happen in practice.

It would be good to add a comment explaining why the options are
added (aka just don't skip any pages).
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Next
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions