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
- reloptions_freeze.patch (text/x-diff) patch
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
-
Improve stability of test with vacuum_truncate in reloptions.sql
- bada6280f0b9 12.7 landed
- 89937d001294 13.3 landed
- fe246d1c111d 14.0 landed