Re: Avoid endless futile table locks in vacuuming. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Avoid endless futile table locks in vacuuming.
Date
Msg-id 2788.1451241191@sss.pgh.pa.us
Whole thread Raw
In response to Avoid endless futile table locks in vacuuming.  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Avoid endless futile table locks in vacuuming.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> If a partially-active table develops a slug of stable all-visible,
> non-empty pages at the end of it, then every autovacuum of that table
> will skip the end pages on the forward scan, think they might be
> truncatable, and take the access exclusive lock to do the truncation.
> And then immediately fail when it sees the last page is not empty.
> This can persist for an indefinite number of autovac rounds.

> This is not generally a problem, as the lock is taken conditionally.
> However, the lock is also logged and passed over to any hot standbys,
> where it must be replayed unconditionally.  This can cause query
> cancellations.

> The simple solution is to always scan the last page of a table, so it
> can be noticed that it is not empty and avoid the truncation attempt.

This seems like a reasonable proposal, but I find your implementation
unconvincing: there are two places in lazy_scan_heap() that pay attention
to scan_all, and you touched only one of them.  Thus, if we fail to
acquire cleanup lock on the table's last page on the first try, the
change is for naught.  Shouldn't we be insisting on getting that lock?
Or, if you intentionally didn't change that because it seems like too
high a price to pay, why doesn't the comment reflect that?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Grzegorz Sampolski
Date:
Subject: Re: pam auth - add rhost item
Next
From: Artur Zakirov
Date:
Subject: Re: Fuzzy substring searching with the pg_trgm extension