Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7
| От | Tom Lane |
|---|---|
| Тема | Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7 |
| Дата | |
| Msg-id | 23358.1244569634@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7 (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [BUGS] Cursor with hold emits the same row more than
once across commits in 8.3.7
Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7 |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@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 cursor.
I don't mind paying it for a WITH HOLD cursor, since by definition
you're asking for a more expensive behavior there. The thing that is
bothering me more is whether we want to pay a price for a *non* WITH
HOLD cursor. You can get instability for seqscan or volatile functions
if you just try MOVE BACKWARD ALL and re-read.
regards, tom lane
В списке pgsql-hackers по дате отправления: