> -----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,
