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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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