mysterious nbtree.c comment

Поиск
Список
Период
Сортировка
От Greg Stark
Тема mysterious nbtree.c comment
Дата
Msg-id 874pxys9zt.fsf@stark.xeocode.com
обсуждение исходный текст
Ответы Re: mysterious nbtree.c comment  (Simon Riggs <simon@2ndquadrant.com>)
Re: mysterious nbtree.c comment  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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. 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.


Datum
btvacuumcleanup(PG_FUNCTION_ARGS)
{IndexVacuumInfo *info = (IndexVacuumInfo *) PG_GETARG_POINTER(0);IndexBulkDeleteResult *stats = (IndexBulkDeleteResult
*)PG_GETARG_POINTER(1);
 
/* * If btbulkdelete was called, we need not do anything, just return * the stats from the latest btbulkdelete call.
Ifit wasn't called, * we must still do a pass over the index, to recycle any newly-recyclable * pages and to obtain
indexstatistics. * * Since we aren't going to actually delete any leaf items, there's no * need to go through all the
vacuum-cycle-IDpushups. */if (stats == NULL){    stats = (IndexBulkDeleteResult *)
palloc0(sizeof(IndexBulkDeleteResult));   btvacuumscan(info, stats, NULL, NULL, 0);}
 


-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruno Wolff III
Дата:
Сообщение: Re: Transaction and table partitioning
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: mysterious nbtree.c comment