On Wed, Apr 8, 2015 at 06:41:55PM +0000, maciek@heroku.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 13002
> Logged by: Maciek Sakrejda
> Email address: maciek@heroku.com
> PostgreSQL version: 9.3.6
> Operating system: Ubuntu 14.04
> Description:
>
> If autovacuum is running a VACUUM to prevent wraparound on a certain table,
> it looks like it blocks TRUNCATE of that table, which would obviate the need
> for the VACUUM in the first place (and could happen much more quickly). This
> seems like a usability wart at best--one has to instead kill the autovacuum
> (e.g., via pg_cancel_backend) and then TRUNCATE. This is especially
> inconvenient when the user trying to truncate does not have permission to
> kill (or even see!) the wraparound VACUUM. Would it be possible to have
> autovacuum yield to a TRUNCATE in this situation?
My guess is this would be hard to do. VACUUM and TRUNCATE request
conflicting locks, so you would have to embed in the locking code that
the _outcome_ of one should allow it to override the lock of the other.
I can't think of anywhere that we allow that. Frankly, you can't really
just ignore the lock --- you would have to cancel the vacuum by sending
a signal or something. I know we have cases where vacuum aborts if it
can't get a lock or something, but I can't remembrer any case where we
externally cancel vacuum like that.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
