| From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <janwieck(at)Yahoo(dot)com> |
| Cc: | PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: Wrong FOR UPDATE lock type |
| Date: | 2000-12-05 18:49:01 |
| Message-ID: | 8F4C99C66D04D4118F580090272A7A234D31C9@sectorbase1.sectorbase.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Well, there is a theoretical chance of deadlock --- not against other
> transactions doing the same thing, since RowShareLock and
> RowExclusiveLock don't conflict, but you could construct deadlock
> scenarios involving other transactions that grab ShareLock or
> ShareRowExclusiveLock. So I don't think it's appropriate for the
> "deadlock risk" check to ignore RowShareLock->RowExclusiveLock
> upgrades.
There is theoretical chance of deadlock when two xactions lock
tables in different order and we can check this only in deadlock
detection code.
> But I'm not sure the check should be enabled in production releases
> anyway. I just put it in as a quick and dirty debug check. Perhaps
> it should be under an #ifdef that's not enabled by default.
No reason to learn users during transaction processing. We need in
good deadlock detection code and documentation.
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martin A. Marques | 2000-12-05 19:23:40 | Re: beta testing version |
| Previous Message | Mikheev, Vadim | 2000-12-05 18:43:03 | RE: beta testing version |