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

From Tom Lane
Subject Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7
Date
Msg-id 23358.1244569634@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7  (Robert Haas <robertmhaas@gmail.com>)
Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Not quite a security hole in internal_in
Next
From: Jeff Davis
Date:
Subject: Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7