Re: FOR SHARE vs FOR UPDATE locks

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: FOR SHARE vs FOR UPDATE locks
Дата
Msg-id b42b73150612011211x2eac43e1h66717bb3a687293b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: FOR SHARE vs FOR UPDATE locks  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [CORE] FOR SHARE vs FOR UPDATE locks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 12/1/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> > Let's throw an error for now. We have to come back to this in 8.3, I think.
>
> After further thought I think we should also seriously consider plan C:
> do nothing for now.  We now realize that there have been related bugs
> since 8.0, namely that
>
>         begin;
>         select some rows for update;
>         savepoint x;
>         update the same rows;
>         rollback to x;
>
> leaves the tuple(s) not locked.  The lack of complaints about this from
> the field suggests that this isn't a huge problem in practice.  If we
> do make it throw an error I'm afraid that we will break applications
> that aren't having a problem at the moment.

imo, the most likely scenario would be a begin/exception/end block in
pg/sql. i would venture to guess that very little true savepointing
happens in practice.  maybe add a little note of caution pg/sql error
handling documentation?

merlin


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [CORE] FOR SHARE vs FOR UPDATE locks
Следующее
От: Zdenek Kotala
Дата:
Сообщение: Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3)