Re: Flaky vacuum truncate test in reloptions.sql

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Arseny Sher <a(dot)sher(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Flaky vacuum truncate test in reloptions.sql
Date: 2021-04-01 04:28:19
Message-ID: YGVL46GoetxG08LF@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2021-04-01 05:58:28 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Amit Kapila 2021-04-01 04:26:45 Re: Parallel INSERT (INTO ... SELECT ...)