RE: [HACKERS] Lock freeze ? in MVCC
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] Lock freeze ? in MVCC |
Дата | |
Msg-id | 002301be915d$94c86660$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Lock freeze ? in MVCC (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
> -----Original Message----- > From: root@sunpine.krs.ru [mailto:root@sunpine.krs.ru]On Behalf Of Vadim > Mikheev > Sent: Tuesday, April 27, 1999 7:49 PM > To: Hiroshi Inoue > Cc: Bruce Momjian; pgsql-hackers@postgreSQL.org > Subject: Re: [HACKERS] Lock freeze ? in MVCC > > > Hiroshi Inoue wrote: > > > > Now I'm suspicious about the following code in LockResolveConflicts(). > > > > /* > > * We can control runtime this option. Default is > lockReadPriority=0 > > */ > > if (!lockReadPriority) > > { > > /* ------------------------ > > * If someone with a greater priority is waiting for the > > lock, > > * do not continue and share the lock, even if > we can. bjm > > * ------------------------ > > You're right Hiroshi - this must be changed: > > if we already have some lock with priority X and new requested > lock has priority Y, Y <= X, then lock must be granted. > > Also, I would get rid of lockReadPriority stuff... > I found a problem to get rid of lockReadPriority stuff completely. If there's a table which is insert/update/deleted very frequenly by several processes,processes which request the high priority lock (such as vacuum) could hardly acquire the lock for the table. How about the following patch ? Thanks. Hiroshi Inoue Inoue@tpf.co.jp *** storage/lmgr/lock.c.orig Wed Apr 28 10:44:52 1999 --- storage/lmgr/lock.c Wed Apr 28 12:00:14 1999 *************** *** 815,821 **** /* * We can control runtime this option. Default is lockReadPriority=0 */ ! if (!lockReadPriority) { /* ------------------------ * If someone with a greater priority is waitingfor the lock, --- 815,821 ---- /* * We can control runtime this option. Default is lockReadPriority=0 */ ! if ((!result->nHolding) && (!lockReadPriority)) { /* ------------------------ * If someone witha greater priority is waiting for the lock,
В списке pgsql-hackers по дате отправления: