Re: BUG #5946: Long exclusive lock taken by vacuum (not full) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Date
Msg-id 15329.1301082238@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Greg Stark <gsstark@mit.edu>)
List pgsql-bugs
Alvaro Herrera <alvherre@commandprompt.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

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Next
From: Greg Stark
Date:
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)