Re: lock problem
| От | Rural Hunter |
|---|---|
| Тема | Re: lock problem |
| Дата | |
| Msg-id | 4EF28B8A.1060602@gmail.com обсуждение исходный текст |
| Ответ на | Re: lock problem ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
| Список | pgsql-admin |
hmm....no I didn't do anything. is the lock priority decided by OS not the DB? I'm confused here. B/C/D started several mins later than A here while the update statement takes no more than 1 second. of coz there are hundreds of connections trying to acquire the lock during that time. 于2011年12月22日 0:09:17,Kevin Grittner写到: > Rural Hunter<ruralhunter@gmail.com> wrote: > >> I still have this question: >> same statement A,B,C,D update same row. The start order is >> A->B->C-D. From what I've gotten, B/C/D got the lock before A. >> Why did that happen? > > Did you do anything to prevent it from happening? If not, the OS > scheduler is going to give time to one process or another in a > fairly unpredictable way. > > -Kevin >
В списке pgsql-admin по дате отправления: