Re: reloption to prevent VACUUM from truncating empty pages at theend of relation - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Date
Msg-id CAD21AoAQQUnYuMzcdFh-qznxF40AeNv=t-Tr=8_LX=TZGzfH9A@mail.gmail.com
Whole thread Raw
In response to RE: reloption to prevent VACUUM from truncating empty pages at theend of relation  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
List pgsql-hackers
On Tue, Feb 26, 2019 at 3:29 PM Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
>
> From: Masahiko Sawada [mailto:sawada.mshk@gmail.com]
> > This test expects that the inserted tuple is always reclaimed by
> > subsequent vacuum, but it's not always true if there are concurrent
> > transactions. So size of the reloptions_test table will not be 0 if
> > the tuple is not vacuumed. In my environment this test sometimes
> > failed with 'make check -j 4'.
>
> Hmm, "make check -j4" certainly fails on my poor VM, too.
>
> Modifying src/test/regress/parallel_schedule to put the reloptions test on a separate line seems to have fixed this
issue. Do you think this is the correct remedy?
 
>

Yeah, that would work. Or it's kind of hackie but the rolling back the
insertion instead of INSERT and DELETE might also work.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [RFC] [PATCH] Flexible "partition pruning" hook
Next
From: Michael Paquier
Date:
Subject: Re: BUG #15589: Due to missing wal, restore ends prematurely andopens database for read/write