RE: [HACKERS] Lock freeze ? in MVCC

> -----Original Message-----
> From: root(at)sunpine(dot)krs(dot)ru [mailto:root(at)sunpine(dot)krs(dot)ru]On Behalf Of Vadim
> Mikheev
> Sent: Tuesday, April 27, 1999 7:49 PM
> To: Hiroshi Inoue
> Cc: Bruce Momjian; pgsql-hackers(at)postgreSQL(dot)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(at)tpf(dot)co(dot)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 waiting for the lock,
--- 815,821 ----
/*
* We can control runtime this option. Default is lockReadPriority=0
*/
! if ((!result->nHolding) && (!lockReadPriority))
{
/* ------------------------
* If someone with a greater priority is waiting for the lock,