Re: Think I see a btree vacuuming bug - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Think I see a btree vacuuming bug
Date
Msg-id 200208262148.g7QLmQM21849@candle.pha.pa.us
Whole thread Raw
In response to Re: Think I see a btree vacuuming bug  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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@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
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Think I see a btree vacuuming bug
Next
From: Bruce Momjian
Date:
Subject: Re: Default privileges for new databases (was Re: Can't import