On 1/29/15 4:02 PM, Robert Haas wrote:
> On Thu, Jan 29, 2015 at 4:09 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>>> The difference between the autovacuum-run vacuum and the cron-run vacuum
>>> is that the one running out of cron will just keep holding the lock
>>> until it's actually able to truncate the end of the relation, no? I
>>> recall discussion previously that we need a way to either support that
>>> in autovacuum for (a configurable set of) regular relations or come up
>>> with a solution that doesn't require that lock.
>>
>> AFAICT, in master, there is no difference in truncation between auto and
>> manual vacuum. What we do is attempt to acquire the truncation lock for up
>> to 5 seconds, giving up after that. Once we do have the lock, we check to
>> see how many pages we can actually truncate. During that check, we test
>> every ~20ms or so to see if someone else is waiting on our exclusive lock;
>> if they are we stop counting and will only truncate the relation up to that
>> point.
>
> I don't think this is true, and I don't think it's been true for a
> long time, if ever. The difference between a manual vacuum and
> autovacuum is that autovacuum commits suicide when it conflicts with
> somebody else's lock request, and a manual vacuum doesn't.
Any idea where we set that up? The call stack is (note I'm ignoring vacuum full) autovacuum_do_vac_analyze() ->
vacuum()-> vacuum_rel() -> lazy_vacuum_rel() -> lazy_truncate_heap() (which also calls count_nondeletable_pages()), and
Idon't see any IsAutoVacuumWorkerProcess() calls in lazy_truncate_heap or count_nondeletable_pages(). So AFAICT
truncationoperates the same regardless of how the vacuum was started. We also explicitly set things like
statement_timeoutto 0 in autovac, so I don't think that would be responsible for this...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com