Jeff Janes writes:
> So like the attached, although it is a bit weird to call
> lazy_check_needs_freeze if , under !scan_all, we don't actually care
> about whether it needs freezing but only the hastup.
I think this misses unpinning the buffer in the added code path.
I rearranged to avoid that,
Jeff Janes writes:
> On Dec 29, 2015 4:47 PM, "Tom Lane" wrote:
>> Uh, isn't that what my patch is doing?
> My reading was it does that only if there are no tuples that could be
> frozen. If there are tuples that could be frozen, it actually does
> the freezing, even though that is not necessar
Forgetting to CC the list is starting to become a bad habit, sorry.
forwarding to list:
-- Forwarded message --
From: Jeff Janes
Date: Wed, Dec 30, 2015 at 10:03 AM
Subject: Re: [HACKERS] Avoid endless futile table locks in vacuuming.
To: Tom Lane
On Dec 29, 2015 4:47 PM, &quo
Jeff Janes writes:
> If we are not doing a scan_all and we fail to acquire a clean-up lock on
> the last block, and the last block reports that it needs freezing, then we
> continue on to wait for the clean-up lock. But there is no need, we don't
> really need to freeze the block, and we already k
On Mon, Dec 28, 2015 at 2:12 PM, Tom Lane wrote:
> I wrote:
>> Jeff Janes 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
>
I wrote:
> Jeff Janes 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
Jeff Janes 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.
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 w