Re: Think I see a btree vacuuming bug

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(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:48:26
Message-ID: 200208262148.g7QLmQM21849@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> 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.

Yes. Considering there are splits going on where backends are losing
their pins, it seems you have to either prevent the backends from losing
their pins, prevent the splits, or prevent vacuum from removing tuples
on split pages that hold pins.

Rather than having vacuum pin all the pages, could vacuum block in cases
where pins exist in pages that _could_ contain tuples caused by a recent
split, meaning there are pins in pre-split locations?

> > 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.

So it uses the tid to find the old spot. Got it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-08-26 22:03:06 Re: Default privileges for new databases (was Re: Can't import
Previous Message Tom Lane 2002-08-26 21:36:53 Re: Think I see a btree vacuuming bug