Tom Lane wrote:
> If a VACUUM running concurrently with someone else's indexscan were to
> delete the index tuple that the indexscan is currently stopped on, then
> we'd get a failure when the indexscan resumes and tries to re-find its
> place. (This is the infamous "my bits moved right off the end of the
> world" error condition.) What is supposed to prevent that from
Certainly anything that makes this error message less likely is bad.
Perhaps we need to hook up a random() call to output the error message
to balance this. :-)
> happening is that the indexscan retains a buffer pin (but not a read
> lock) on the index page containing the tuple it's stopped on. VACUUM
> will not delete any tuple until it can get a "super exclusive" lock on
> the page (cf. LockBufferForCleanup), and the pin prevents it from doing
> so.
>
> However: suppose that some other activity causes the index page to be
> split while the indexscan is stopped, and that the tuple it's stopped
> on gets relocated into the new righthand page of the pair. Then the
> indexscan is holding a pin on the wrong page --- not the one its tuple
> is in. It would then be possible for the VACUUM to arrive at the tuple
> and delete it before the indexscan is resumed.
OK, let me see if I can summarize:
Index scan stops on dead index tuple, holds pinSomeone inserts/updates and the page splitsVacuum comes along and
removesthe index tuple
And the problem is that after the split, the index scan doesn't hold a
pin on the newly split page.
This seems more like a problem that the index scan pin doesn't prevent
it from losing the pin after a split. Could we just block splits of
pages containing pins? If the page splits, how does the index scan
find the new page to start again? Could the index scan be made to
handle cases where the index tuple it was stopped on is gone?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
