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

From Robert Haas
Subject Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7
Date
Msg-id 603c8f070906091037l3a748fc8m11ca40cb4b7fe8f7@mail.gmail.com
Whole thread Raw
In response to Re: 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-bugs
On Tue, Jun 9, 2009 at 12:07 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> The technically best solution is probably similar to what Materialize
> nodes do, ie, read the query only once and be careful to stash rows
> aside into a tuplestore as they are read.  This would fix both issues
> with one patch.  The problem with that is that if the user doesn't
> actually do any backwards fetching, you waste all the tuplestore
> maintenance work.

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 suppose in theory you could try to figure out whether
materialization is really necessary (let's see... no seqscans here and
no volatile functions...  ok, so we can cheat...) but that seems
likely to lead to future bugs as the rules for which things are safe
change.

...Robert


pgsql-bugs by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7
Next
From: Jaime Casanova
Date:
Subject: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7