To: Teodor Sigaev <teodor@sigaev.ru>
cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] GIN improvements 
In-reply-to: <7913.1216918895@sss.pgh.pa.us> 
References: <483FD205.4090904@sigaev.ru> <486BC501.6060605@sigaev.ru>
	<27880.1215810535@sss.pgh.pa.us> <487A6E0C.3090600@sigaev.ru>
	<8993.1216843701@sss.pgh.pa.us> <4888A594.6010102@sigaev.ru>
	<7913.1216918895@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 24 Jul 2008 13:01:35 -0400"
Date: Thu, 24 Jul 2008 13:20:42 -0400
Message-ID: <8177.1216920042@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:
> Really?  Then GiST needs to be fixed too.  Otherwise you risk having
> queries return the same row twice.  A bitmap indexscan plan would mask
> such an index bug ... but a plain indexscan won't.

BTW, there's another issue I forgot about yesterday, which is that
the planner assumes that all index AMs work correctly for backwards
scan.  The place where the rubber meets the road here is that
if you DECLARE SCROLL CURSOR for a plan implemented as a plain
indexscan, then FETCH BACKWARDS is supposed to reliably generate
results consistent with previous FETCH FORWARDS, to wit the same
tuples in the reverse order.

We can assume that the query is using an MVCC snapshot, which means
that at the index level it's okay for the index to return newly-inserted
entries that weren't returned in the previous forward scan, or to not
return entries that were removed meanwhile by VACUUM.  But re-ordering
live tuples is bad news.

The idea of copying the pending-tuples list into local scan state would
make this work as expected as far as the proposed patch goes, but I'm
wondering whether the behavior isn't completely broken anyway by
operations such as page splits.  Do we need to change the planner to
assume that this only works nicely for btree?

			regards, tom lane