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
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
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
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.
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.
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
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
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
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