Re: possible concurrency bug or mistake in understanding read-committed behavior
| От | Kevin Grittner |
|---|---|
| Тема | Re: possible concurrency bug or mistake in understanding read-committed behavior |
| Дата | |
| Msg-id | 4CE2B0BA0200002500037858@gw.wicourts.gov обсуждение исходный текст |
| Ответ на | Re: possible concurrency bug or mistake in understanding read-committed behavior (Jignesh Shah <jkshah@gmail.com>) |
| Ответы |
Re: possible concurrency bug or mistake in
understanding read-committed behavior
|
| Список | pgsql-hackers |
Jignesh Shah <jkshah@gmail.com> wrote: > The question is should the delete fail if it doesn't exist and > cause a rollback or succeed with DELETE 0 ? I think existing behavior is consistent with both the standard and the other behaviors of PostgreSQL at the READ COMMITTED isolation level. I might have found it surprising at first glance except that there was a recent discussion about why an INSERT on one transaction doesn't stand in the way of a concurrent UPDATE in another transaction at that level. (I don't want to exhibit surprise again so soon -- it might scare Bruce. ;-) ) This example does cause a serialization failure at the REPEATABLE READ level as well as at the SERIALIZABLE level with the SSI patch, which all seems sane to me, too. -Kevin
В списке pgsql-hackers по дате отправления: