Re: heap vacuum & cleanup locks

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Itagaki Takahiro <itagaki.takahiro@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-06-06T06:00:15Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Make VACUUM avoid waiting for a cleanup lock, where possible.

On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> On Sun, Jun 5, 2011 at 12:03, Robert Haas <robertmhaas@gmail.com> wrote:
>> If other buffer pins do exist, then we can't
>> defragment the page, but that doesn't mean no useful work can be done:
>> we can still mark used line pointers dead, or dead line pointers
>> unused.  We cannot defragment, but that can be done either by the next
>> VACUUM or by a HOT cleanup.
>
> This is just an idea -- Is it possible to have copy-on-write techniques?
> VACUUM allocates a duplicated page for the pinned page, and copy valid
> tuples into the new page. Following buffer readers after the VACUUM will
> see the cloned page instead of the old pinned one.

Heikki suggested the same thing, and it's not a bad idea, but I think
it would be more work to implement than what I proposed.  The caller
would need to be aware that, if it tries to re-acquire a content lock
on the same page, the offset of the tuple within the page might
change.  I'm not sure how much work would be required to cope with
that possibility.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company