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

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 (view raw or flat)
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

pgsql-bugs by date

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

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