Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7
Date
Msg-id 603c8f070906091100v1e991c97y8e58e62153efac2a@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jun 9, 2009 at 1:47 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> This seems like the only option that will produce correct answers, so
>> it gets my vote.  How much is the performance penalty for
>> materializing the tuplestore?  I'm inclined to think that whatever it
>> is, you just have to pay it if you ask for a WITH HOLD cursor.
>
> I don't mind paying it for a WITH HOLD cursor, since by definition
> you're asking for a more expensive behavior there.  The thing that is
> bothering me more is whether we want to pay a price for a *non* WITH
> HOLD cursor.  You can get instability for seqscan or volatile functions
> if you just try MOVE BACKWARD ALL and re-read.

[ reads the fine manual ]

It seems like we need to materialize if you ask for WITH HOLD or
SCROLL.  I guess the question is what to do if you haven't specified
either and then try to scroll anyway.  The manual says that it may
fail, but it doesn't say that might seem to work but actually return
wrong answers.

...Robert


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Multicolumn index corruption on 8.4 beta 2
Next
From: "Kevin Grittner"
Date:
Subject: Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7