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

From Zeugswetter Andreas SB SD
Subject Re: Think I see a btree vacuuming bug
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E64@m0114.s-mxs.net
Whole thread Raw
In response to Think I see a btree vacuuming bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Think I see a btree vacuuming bug  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > 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.

Won't it still point to the same heap page and slot ? That additional info
should be sufficient to find the exact index tuple.
And it usually won't be that far away, no ?

Andreas


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: MemoryContextAlloc: invalid request size 1934906735
Next
From: "Christopher Kings-Lynne"
Date:
Subject: REINDEX ALL and CLUSTER ALL