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

From Dimitri Fontaine
Subject Re: autovacuum truncate exclusive lock round two
Date
Msg-id m24nkq8pm4.fsf@2ndQuadrant.fr
Whole thread Raw
In response to autovacuum truncate exclusive lock round two  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: autovacuum truncate exclusive lock round two
List pgsql-hackers
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 would allow removing 2 of the 3 GUCs below:

>     autovacuum_truncate_lock_check = 100ms # how frequent to check
>                                            # for conflicting locks

This is the one remaining. Could we maybe check for lock conflict after
every move backward a page, or some multiple thereof? The goal would be
to ensure that progress is made, while also being aware of concurrent
activity, ala CHECK_FOR_INTERRUPTS().

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Index only scans wiki page
Next
From: Alvaro Herrera
Date:
Subject: Re: autovacuum truncate exclusive lock round two