References: <87tuotr2hh.fsf@ars-thinkpad> <YGLOWsO2bV7KLvh7@paquier.xyz>
 <78aad736-c653-92fd-45ac-4482729459c6@postgrespro.ru>
 <CAD21AoB+qb-sOY2QeTnGirjh-UvFJj8eANVwQ4CV-r+t1AhxDA@mail.gmail.com>
 <d5dd7eaf-0ba1-a18b-1ef2-552196f36a71@postgrespro.ru>
 <CAD21AoBrNFeBRT-AkVyMybr=bmUbiAcpZPsD61Q_tgvAUqUuHQ@mail.gmail.com>
User-agent: mu4e 1.2.0; emacs 26.0.50
From: Arseny Sher <a.sher@postgrespro.ru>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Flaky vacuum truncate test in reloptions.sql
In-reply-to: 
 <CAD21AoBrNFeBRT-AkVyMybr=bmUbiAcpZPsD61Q_tgvAUqUuHQ@mail.gmail.com>
Date: Thu, 01 Apr 2021 06:08:28 +0300
Message-ID: <87sg4ar9ar.fsf@ars-thinkpad>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
 <https://www.postgresql.org/message-id/87sg4ar9ar.fsf%40ars-thinkpad>
Precedence: bulk


Masahiko Sawada <sawada.mshk@gmail.com> writes:

>> I don't think this matters much, as it tests the contrary and the
>> probability of
>> successful test passing (in case of theoretical bug making vacuum to
>> truncate
>> non-empty relation) becomes stunningly small. But adding it wouldn't hurt
>> either.
>
> I was concerned a bit that without FREEZE in the first VACUUM we could
> not test it properly because the table could not be truncated because
> either vacuum_truncate is off

FREEZE won't help us there.

> or the page is skipped.

You mean at the same time there is a potential bug in vacuum which would
force the truncation of non-empy relation if the page wasn't locked?
That would mean the chance of test getting passed even single time is
close to 0, as currently the chance of its failure is close to 1.


-- cheers, arseny