On 1/29/15 4:02 PM, Robert Haas wrote:
On Thu, Jan 29, 2015 at 4:09 PM, Jim Nasby <jim.na...@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

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 I don't see any 
IsAutoVacuumWorkerProcess() calls in lazy_truncate_heap or count_nondeletable_pages(). So 
AFAICT truncation operates the same regardless of how the vacuum was started. We also 
explicitly set things like statement_timeout to 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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to