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

Re: Think I see a btree vacuuming bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Think I see a btree vacuuming bug
Date: 2002-08-26 21:36:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Could we just block splits of
> pages containing pins?

That's not an improvement IMHO.  The objection to the fix I suggested is
that it makes it harder for VACUUM to make progress in the presence of
contention.  Replacing that with an approach that blocks foreground
processes from making progress is not better.

> If the page splits, how does the index scan
> find the new page to start again?

It moves right until it finds the tuple it was on.  That will either be
in the pinned page, or some page to its right.

> Could the index scan be made to
> handle cases where the index tuple it was stopped on is gone?

Don't see how.  With no equal keys, you could test each tuple you scan
over to see if it's > the expected key; but that would slow things down
tremendously I fear.  In any case it fails completely when there are
equal keys, since you could not tell where in a run of equal keys to
resume scanning.  You really have to find the exact index tuple you
stopped on, AFAICS.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-08-26 21:48:26
Subject: Re: Think I see a btree vacuuming bug
Previous:From: Bruce MomjianDate: 2002-08-26 21:35:20
Subject: Re: Efficient DELETE Strategies

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