Re: mysterious nbtree.c comment - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: mysterious nbtree.c comment
Date
Msg-id 1151962964.2479.319.camel@localhost.localdomain
Whole thread Raw
In response to mysterious nbtree.c comment  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
On Mon, 2006-07-03 at 16:34 -0400, Greg Stark wrote:
> In nbtree.c there's a path that calls btvacuumscan to gather statistics if
> there aren't already statistics. I'm not exactly clear how this code path is
> reached but that's not my question. 

VACUUM calls access/index/index_vacuum_cleanup() which is part of the
btree index access method API. In the case of a btree index this is a
function pointer to access/nbtree/btvacuumcleanup()

That is important to your question.

> There's a comment that "there's no need to
> go through all the vacuum-cycle-ID pushups" in this case because no deletions
> are being performed. 
> 
> I don't see how the lack of deletions is relevant to needing vacuum-cycle-ID.
> AFAICT there's still a risk that someone will come along and do a page split
> underneath this scan and if the page is to the left of the scan it will be
> missed.

Read the comments in btvacuumscan. It is only important to scan all the
pages of an index when deleting leaf items.

The btvacuumscan called from btvacuumcleanup only gets called when stats
are NULL. That only happens when the VACUUM returns no rows for cleanup,
so the scan need only perform one of its three functions: remove pages
already marked as deleted that can now be recycled into the FSM. You're
right - it will be missed but its not crucial to the scan when called in
that way since we'll pick it up next time around.

--  Simon Riggs EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: mysterious nbtree.c comment
Next
From: Andrew Dunstan
Date:
Subject: buildfarm stats