Skip site navigation (1) Skip section navigation (2)

Re: BUG #5946: Long exclusive lock taken by vacuum (not full)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Date: 2011-03-25 19:43:58
Message-ID: 15329.1301082238@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> What happened to the idea of preallocating tables to a size defined by
> the user at CREATE TABLE time, and extending it in chunks instead of a
> block at a time, with the idea of reducing fragmentation?  Was it
> rejected, or just not implemented?

I don't recall any particular discussion of making the user contend with
that.  My thought would be to do something like enlarging the table by
10% anytime we need to extend it.  The main issue here is where to cause
that to happen.  An individual backend that just wants to store one more
tuple probably shouldn't have to do that much work.

> The other possibly useful idea was to let this truncate step to be run
> as a separate activity, without having to complete a vacuum cycle on the
> table.

Yeah.  I did think of a small problem with just letting autovac get
blown off the lock: it will fail to send the stats messages about what
it's done, which will likely result in a near-immediate launch of a new
autovacuum against the table.  It'd be better to complete the autovacuum
and then try to do the truncation in an independent transaction.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Greg StarkDate: 2011-03-25 20:26:26
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Previous:From: Alvaro HerreraDate: 2011-03-25 19:26:33
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group