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  (Robert Haas <robertmhaas@gmail.com>)
Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Not quite a security hole in internal_in
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7