Hannu Krosing <hannu@tm.ee> writes:
> Tom Lane kirjutas R, 14.02.2003 kell 01:13:
>> How is returning the same data twice not an "ill effect"?
> From earlier discussions I understood that there had been some work done
> on using btrees for indexing arrays by storing each separate element in
> a l�eaf node. Surely that work must deal with not returning the same
> tuple twice.
The only mechanism that exists for that is to discard tuples that meet
the qualification tests of previous indexscans. This cannot prevent
returning the same tuple twice in one scan, if the index is so
ill-behaved as to return the same pointer twice. I don't know what
Vadim had in mind to support multiple index entries per tuple, but
it's certainly not in the code yet.
>> How will you wait for scans that you know nothing of to go past?
>> Especially when they are going to be blocked by your own write lock
>> on the left page?
> could we just not lock (for more than just to ensure atomic writes) the
> page but instead increment a "page version" on each write to detect
> changes?
How does that help? The left-moving indexscan still has no way to
recover. It can't go back to the page it was on before and try to
determine which entries you added there, because it has no reliable
reference point to do so. The entry it previously returned might not be
there anymore, and in a non-unique index key comparisons won't help.
And even more to the point, how would it know you've changed the left
page? It has no idea what the previous "page version" on the left page
was, because it was never there before.
regards, tom lane
