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

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

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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