On Thu, Apr 1, 2021 at 12:08 PM Arseny Sher <a.sher@postgrespro.ru> wrote:
>
>
> 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?
Just to be clear the context, I’m mentioning the following test case:
CREATE TABLE reloptions_test(i INT NOT NULL, j text)
WITH (vacuum_truncate=false,
toast.vacuum_truncate=false,
autovacuum_enabled=false);
SELECT reloptions FROM pg_class WHERE oid = 'reloptions_test'::regclass;
INSERT INTO reloptions_test VALUES (1, NULL), (NULL, NULL);
VACUUM reloptions_test;
SELECT pg_relation_size('reloptions_test') > 0;
What I meant is that without FREEZE option, there are two possible
cases where the table is not truncated (i.g.,
pg_relation_size('reloptions_test') > 0 is true): the page got empty
by vacuum but is not truncated because of vacuum_truncate = false, and
the page could not be vacuumed (i.g., tuples remain in the page)
because the page is skipped due to conflict on cleanup lock on the
page. This test is intended to test the former case. I guess adding
FREEZE will prevent the latter case.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
