Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-10 Thread Tom Lane
Given that RC freeze is nearly upon us for 8.4, and that we need a reasonably non-invasive fix for 8.3 anyway, I propose that for now we just deal with the syncscan issue by tweaking heap_rescan so that rs_startblock doesn't get changed. It looks like that's about a three-line patch. The

Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-10 Thread Mark Kirkwood
Tom Lane wrote: Given that RC freeze is nearly upon us for 8.4, and that we need a reasonably non-invasive fix for 8.3 anyway, I propose that for now we just deal with the syncscan issue by tweaking heap_rescan so that rs_startblock doesn't get changed. It looks like that's about a three-line

Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-09 Thread Tom Lane
Mark Kirkwood mark.kirkw...@catalyst.net.nz writes: A construction of the form DECLARE cur CURSOR WITH HOLD FOR SELECT * FROM obj loop FETCH 1000 FROM cur process 'em COMMIT results in some of the same rows being emitted more than once, altho the final rowcount is correct

Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-09 Thread Robert Haas
On Tue, Jun 9, 2009 at 12:07 PM, Tom Lanet...@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.  

Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-09 Thread Alvaro Herrera
Robert Haas escribió: 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.

Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-09 Thread Tom Lane
Robert Haas robertmh...@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

Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-09 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@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

Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-09 Thread Robert Haas
On Tue, Jun 9, 2009 at 1:47 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@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

Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7

2009-06-09 Thread Jaime Casanova
On Tue, Jun 9, 2009 at 1:00 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: the same paragraph: The default is to allow scrolling in some cases; in some cases... like in but not all... ? this doesn't sound like a vow to me. if the user really wants SCROLLing ability he should have been