|From:||Arseny Sher <a(dot)sher(at)postgrespro(dot)ru>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Flaky vacuum truncate test in reloptions.sql|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Michael Paquier <michael(at)paquier(dot)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
|Next Message||Heikki Linnakangas||2021-04-01 08:09:02||Re: Perform COPY FROM encoding conversions in larger chunks|
|Previous Message||Laurenz Albe||2021-04-01 07:54:20||Re: Issue with point_ops and NaN|