From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Vadim Mikheev" <vadim(at)krs(dot)ru> |
Cc: | "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Lock freeze ? in MVCC |
Date: | 1999-04-28 09:57:52 |
Message-ID: | 002301be915d$94c86660$2801007e@cadzone.tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----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,
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-04-28 10:55:54 | Re: [HACKERS] Lock freeze ? in MVCC |
Previous Message | Oleg Bartunov | 1999-04-28 08:38:44 | Re: [HACKERS] EGCS becomes GCC |