From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7 |
Date: | 2009-06-09 17:37:07 |
Message-ID: | 603c8f070906091037l3a748fc8m11ca40cb4b7fe8f7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Jun 9, 2009 at 12:07 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-06-09 17:38:51 | Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7 |
Previous Message | Tom Lane | 2009-06-09 16:07:44 | Re: Cursor with hold emits the same row more than once across commits in 8.3.7 |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-06-09 17:37:35 | Re: Multicolumn index corruption on 8.4 beta 2 |
Previous Message | Robert Haas | 2009-06-09 17:28:37 | Re: Not quite a security hole in internal_in |