Re: Hung Vacuum in 8.3

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Hung Vacuum in 8.3
Date: 2011-02-22 21:20:13
Message-ID: 4D64288D.4080402@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 23/02/11 03:27, Robert Haas wrote:
> On Tue, Feb 22, 2011 at 6:26 AM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
>> Actually it's not waiting for the LockBuffer LWLock. it's waiting
>> until your query unpins the buffer it wants. Vacuum tries to get an
>> exclusive lock on the buffer, if it gets it then it checks if anyone
>> is using that buffer. If someone is then it unlocks the buffer and
>> waits until nobody has it pinned.
> How bad it would be if we made LockBufferForCleanup() not wait? If we
> can't obtain the buffer cleanup lock immediately, we just skip that
> page and continue on. That would prevent us from updating
> relfrozenxid, I guess, but we already can't do that if there are any
> bits set in the visibility map. It could also leave some bloat in
> the table, but probably not much (he says hopefully).
>

Seems like a good suggestion, and may leave less bloat than having the
vacuum hung for potentially quite some time.

Mark

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Eric Schwarzenbach 2011-02-22 21:28:39 Re: BUG #5898: Nested "in" clauses hide bad column names
Previous Message Mark Kirkwood 2011-02-22 21:18:39 Re: Hung Vacuum in 8.3