Re: vac truncation scan problems

Hi, this is a bug in the commit 0d831389749a3baaced7b984205b9894a82444b9 .

It allows vucuum freeze to be skipped and inversely lets regular
vacuum wait for lock. The attched patch fixes it.

In table_recheck_autovac, vacuum options are determined as following,

> tab->at_vacoptions = VACOPT_SKIPTOAST |
> (dovacuum ? VACOPT_VACUUM : 0) |
> (doanalyze ? VACOPT_ANALYZE : 0) |
!> (wraparound ? VACOPT_NOWAIT : 0);

The line prefixed by '!' looks inverted.

At Mon, 30 Mar 2015 23:42:51 -0700, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote in <CAMkU=1xmTEiaY=5oMHsSQo5vd9V1Ze4kNLL0qN2eH0P_GXOaYw(at)mail(dot)gmail(dot)com>
jeff.janes> On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > But the perversity is that that conflicting lock request can only be
> > coming, as far as I can tell, from the autovac process. I'm not sure how
> > this happens, as I thought autovac never waited for locks but only obtained
> > one if it were instantaneously available, but that it is the only
> > explanation I can think of.
> >
> > I'm not seeing this in 9.4, but I'm not sure how deterministic it is so
> > maybe that is just luck.
> >

Good catch!

> It looks like the culprit is this:
>
> commit 0d831389749a3baaced7b984205b9894a82444b9
> Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> Date: Wed Mar 18 11:52:33 2015 -0300
>
> Rationalize vacuuming options and parameters
>
> I'd guess the autovac nature of the autovac process is getting lost in
> there where, but I don't see where.

You're right, the patch does something like following,

+ tab->at_vacoptions = VACOPT_SKIPTOAST |
+ (dovacuum ? VACOPT_VACUUM : 0) |
+ (doanalyze ? VACOPT_ANALYZE : 0) |
+ (wraparound ? VACOPT_NOWAIT : 0);
..
- if (!tab->at_wraparound)
- vacstmt.options = VACOPT_NOWAIT;

This inverses the meaning of at_wraparound. No previous version
isn't affected by this.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center