From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] MVCC works in serialized mode! |
Date: | 1998-12-17 06:14:39 |
Message-ID: | 3678A14F.8303814A@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1998-12-17 08:03:18 | Re: [HACKERS] redolog - for discussion |
Previous Message | Vadim Mikheev | 1998-12-17 04:00:58 | Re: [HACKERS] CURRENT: crash in select_view regression test... |