On Wed, Feb 7, 2018 at 12:50 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> Hello,
>
> At Tue, 6 Feb 2018 10:41:22 -0300, Claudio Freire <klaussfreire@gmail.com> wrote in
<CAGTBQpaufC0o8OikWd8=5biXcbYjT51mPLfmy22NUjX6kUED0A@mail.gmail.com>
>> On Tue, Feb 6, 2018 at 10:18 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> > On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI
>> > <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>> >>> It's starting to look like a timing effect indeed.
>> >>
>> >> It seems to be truncation skip, maybe caused by concurrent
>> >> autovacuum.
>> >
>> > Good point, I'll also disable autovacuum on vactst.
>> >
>> >> See lazy_truncate_heap() for details. Updates of
>> >> pg_stat_*_tables can be delayed so looking it also can fail. Even
>> >> though I haven't looked the patch closer, the "SELECT
>> >> pg_relation_size()" doesn't seem to give something meaningful
>> >> anyway.
>> >
>> > Maybe then "explain (analyze, buffers, costs off, timing off, summary
>> > off) select * from vactst" then.
>
> Ah, sorry. I meant by the above that it gives unstable result
> with autovacuum. So pg_relation_size() is usable after you turned
> of autovacuum on the table.
You did mention stats could be delayed
>> > The point is to check that the relation's heap has 0 pages.
>>
>> Attached rebased patches with those changes mentioned above, namely:
>>
>> - vacuum test now creates vactst with autovacuum disabled for it
>> - vacuum test on its own parallel group
>> - use explain analyze instead of pg_relation_size to check the
>> relation is properly truncated
>
> The problematic test was in the 0001..v14 patch. The new
> 0001..v15 is identical to v14 and instead 0003-v8 has additional
> part that edits the test and expects added by 0001 into the shape
> as above. It seems that you merged the fixup onto the wrong
> commit.
>
> And may we assume it correct that 0002 is missing in this
> patchset?
Sounds like I botched the rebase. Sorry about that.
Attached are corrected versions (1-v16 and 3-v9)