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 pa
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 question
Jeff Davis writes:
> On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
>> I don't know what you mean by "frozen" exactly, but the start point of a
>> synchronized scan is stored in shared memory; otherwise, it wouldn't
>> know where to stop.
> Correction: I didn't actually mean _shared_ memory
On Tue, Jun 9, 2009 at 1:47 PM, Tom Lane wrote:
> Robert Haas 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:00 PM, Kevin
Grittner 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 specified that way...
i
On Tue, Jun 9, 2009 at 12:07 PM, Tom Lane 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
Tom Lane wrote:
> Robert Haas 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 WIT
On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
> On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
> > We could probably fix this specific issue by refactoring things in such
> > a way that the seqscan start point is frozen on the first read and
> > re-used after rewinds.
>
> I don't know w
On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
> We could probably fix this specific issue by refactoring things in such
> a way that the seqscan start point is frozen on the first read and
> re-used after rewinds.
I don't know what you mean by "frozen" exactly, but the start point of a
synchr
Robert Haas 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
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
> chang
Mark Kirkwood 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 (i.e some rows end up b
Short Desc: Cursor with hold emits the same row more than once across
commits in 8.3.7
Os : Debian Etch amd64 / Ubuntu Jaunty amd64
Pg : 8.3.7
Build options: Official package and also compiled from source with
--enable-integer-datetimes
Detailed Desc:
A construction of the form
DECLARE cur CU
13 matches
Mail list logo
