Re: [HACKERS] MVCC works in serialized mode!
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] MVCC works in serialized mode! |
Дата | |
Msg-id | 3678A14F.8303814A@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] MVCC works in serialized mode! (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] MVCC works in serialized mode!
Re: [HACKERS] MVCC works in serialized mode! |
Список | pgsql-hackers |
Bruce Momjian wrote: > > > 6. I'm not happy with current deadlock detection code! > > It seems that backend does DeadLockCheck each time > > when timer expired - shouldn't this be done _once_, > > before backend is going to sleep ?! > > Not sure. Now that I think of it, it makes sense that if I go to sleep, > a deadlock is not sudenly going to appear while I am asleep. If a new > process causes a deadlock, the new process that causes it will see it. > > I did not check when I went to sleep because I thought it may be too > cpu-intensive to do checking on every sleep, but now that I remember it, > it may be very trivial in cpu time to do the check on every sleep. > > I recommend changing it to do it just before every sleep. Let me know > if you want me to make the change. May be we could just reduce first sleep time (60 sec is too long), do DeadLockCheck _only once_, after first SIGALARM, and after that just sleep forever ? Why do DeadLockCheck many times ? Let's think more... And please consider when lock conflict occures: 1. One process tries update row being updated by other. 2. When reading/writing hashes (I hope to change btrees to use new buffer context lock code, as heap access methods do,- this is short term locking without deadlocks and so - without using lockmanager). Vadim
В списке pgsql-hackers по дате отправления: