Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

Hello,

At Tue, 6 Feb 2018 10:41:22 -0300, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote in <CAGTBQpaufC0o8OikWd8=5biXcbYjT51mPLfmy22NUjX6kUED0A(at)mail(dot)gmail(dot)com>
> On Tue, Feb 6, 2018 at 10:18 AM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> > On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI
> > <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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.

> > 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?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center