Re: Re: [SQL] possible row locking bug in 7.0.3 & 7.1

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: Re: [SQL] possible row locking bug in 7.0.3 & 7.1
Дата
Msg-id 3AC18259.C5A8B0A9@tpf.co.jp
обсуждение исходный текст
Ответ на Re: Re: [SQL] possible row locking bug in 7.0.3 & 7.1  (Philip Warner <pjw@rhyme.com.au>)
Список pgsql-hackers
Tom Lane wrote:
> 
> Philip Warner <pjw@rhyme.com.au> writes:
> >> The workaround for Forest is to make the final SELECT be a SELECT FOR
> >> UPDATE, so that it's playing by the same rules as the earlier commands.
> 
> > Eek. Does this seem good to you?
> 
> I did call it a workaround ;-)
> 
> I don't think that we dare try to make any basic changes in MVCC for 7.1
> at this late hour, so Forest is going to have to live with that answer
> for awhile.  But I would like to see a cleaner answer in future
> releases.

Is it the MVCC's restriction that each query inside a function
must use the same snapshot ?

> As I've opined before, the whole EvalPlanQual mechanism
> strikes me as essentially bogus in any case...
> 

How would you change it ? UPDATE/SELECT FOR UPDATE have to
SELECT/UPDATE the latest tuples. I don't think of any simple
way for 'SELECT FOR UPDATE' to have the same visibility as
simple SELECT.

regards,
Hiroshi Inoue


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Re: Call for platforms
Следующее
От: Adriaan Joubert
Дата:
Сообщение: ecpg bug and patch