Re: Flaky vacuum truncate test in reloptions.sql

Arseny Sher <a.sher@postgrespro.ru>

From: Arseny Sher <a.sher@postgrespro.ru>
To: Michael Paquier <michael@paquier.xyz>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-01T07:58:25Z
Lists: pgsql-hackers

Attachments

Michael Paquier <michael@paquier.xyz> writes:

> 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:

Sorry, I misremembered the test and assumed the table is non-empty there
while it is empty but vacuum_truncate is disabled. Still, this doesn't
change my conclusion of freezing being not a big deal there due to small
chance of locked page. Anyway, let's finish with this.

> 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).

How about the attached?


-- cheers, arseny


Commits

  1. Improve stability of test with vacuum_truncate in reloptions.sql