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

Re: BUG #5946: Long exclusive lock taken by vacuum (not full)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Browne <cbbrowne(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)commandprompt(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 21:56:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> What seems natural-ish to me might include:
> - Stomping a bit on the FSM replacement to make sure nobody's going to
> be writing to the later extensions;
> - Watching free space during the process so the "first" extension gets
> re-opened up if the free space in the much earlier parts of the table
> (e.g. - that are not planned to be dropped off) is running out.

You seem to be thinking only about the possibility that somebody would
try to write a new tuple into the space-to-be-freed.  The problem that
necessitates use of AccessExclusiveLock is that somebody could be doing
a seqscan that tries to *read* the blocks that are about to be truncated
away.  We can't really improve matters much here unless we think of a
way to fix that.  It would be okay if the scan just ignored blocks it
failed to read, but how do you distinguish the case from a filesystem
error that really should be reported?

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: YAMAMOTO TakashiDate: 2011-03-26 03:26:09
Subject: BUG #5952: SetRWConflict assertion failure
Previous:From: Christopher BrowneDate: 2011-03-25 21:46:21
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)

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