Re: Flaky vacuum truncate test in reloptions.sql

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


Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arseny Sher 2021-04-01 03:11:50 Re: Flaky vacuum truncate test in reloptions.sql
Previous Message David Rowley 2021-04-01 03:06:29 Re: making update/delete of inheritance trees scale better