| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, 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 14:27:53 |
| Message-ID: | AANLkTik6cN+Ku86LU-p1yGAOfTDn_e=vuy6d=D7cjaoA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2011-02-22 16:24:45 | Re: BUG #5896: When server cannot be started, first it says that it couldn't be started and then Server Started |
| Previous Message | Robert Haas | 2011-02-22 14:13:54 | Re: BUG #5679: pgAdminIII 1.12.0 hangs |