Re: vac truncation scan problems

On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> After freeing up the rows at the end of the table so it is eligible for
> truncation, then running a manual VACUUM to actually release the space, I
> kept running into the problem that the truncation scan was consistently
> suspended and then aborted due to a conflicting lock requested/held.
>
> 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.
>

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.

Cheers,

Jeff