Re: lazy vacuum sleeps with exclusive lock on table

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lazy vacuum sleeps with exclusive lock on table
Date: 2007-06-28 22:15:28
Message-ID: 1183068929.3589.11.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2007-06-28 at 17:16 -0400, Alvaro Herrera wrote:

> I noticed that lazy vacuum acquires an exclusive lock at the end, to be
> able to truncate the table. This is not a surprise. If it cannot
> acquire the lock, it simply skips truncating the table and goes on with
> life.
>
> However, what's problematic is that if a non-zero cost delay has been
> set, it will happily take naps while determining what to truncate :-(
> This seems a bad idea. It also may explain why some people is seeing
> autovacuum blocking other processes. It also readily explains why this
> is so when there are no non-granted locks for autovacuum.
>
> Comments? I think we should remove the sleep in the truncate phase.

Do we have any timings for that lock-out? Even with a largish sleep
delay, I can't think it's locked out for that long.

Seems like VACUUM shouldn't try just once to get the lock. It could be
very frustrating to wait hours for a VACUUM to finish, only to find a
small query prevents file truncation. That's just too random. It should
retry as many times as there are blocks for it to truncate i.e. it tries
harder to truncate the more it needs to do so.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-06-28 22:17:06 Re: SetBufferCommitInfoNeedsSave and race conditions
Previous Message Simon Riggs 2007-06-28 22:09:36 Re: SetBufferCommitInfoNeedsSave and race conditions