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
|
Список | 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 по дате отправления: