Re: autovacuum truncate exclusive lock round two - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: autovacuum truncate exclusive lock round two
Date
Msg-id 007e01cdc3bd$62402a60$26c07f20$@kapila@huawei.com
Whole thread Raw
In response to Re: autovacuum truncate exclusive lock round two  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Friday, November 16, 2012 4:09 AM Alvaro Herrera wrote:
> Dimitri Fontaine wrote:
> > Jan Wieck <JanWieck@Yahoo.com> writes:
> > > Use this lmgr feature inside count_nondeletable_pages() of
> vacuumlazy.c to
> > > periodically check, if there is a conflicting lock request waiting.
> If not,
> > > keep going. If there is a waiter, truncate the relation to the point
> checked
> > > thus far, release the AccessExclusiveLock, then loop back to where
> we
> > > acquire this lock in the first place and continue
> checking/truncating.
> >
> > I think that maybe we could just bail out after releasing the
> > AccessExclusiveLock and trust autovacuum to get back to truncating
> that
> > relation later.
> 
> That doesn't work, because the truncating code is not reached unless
> vacuuming actually took place.  So if you interrupt it, it will just not
> get called again later.  Maybe we could have autovacuum somehow invoke
> that separately, but that would require that the fact that truncation
> was aborted is kept track of somewhere.

Won't it have a chance to be handled next time when vacuum will trigger due
to updates/deletes on some other pages.

OTOH, may be next time again the same thing happens and it was not able to
complete the truncate.
So I think it's better to complete first time only, but may be using some
heuristic time for wait and retry rather than
with configuration variables.

With Regards,
Amit Kapila





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [WIP] pg_ping utility
Next
From: Greg Smith
Date:
Subject: Re: Timing events WIP v1