Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Lock freeze ? in MVCC

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
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-29 11:22:25
Message-ID: 372840F1.6069C129@krs.ru (view raw or flat)
Thread:
Lists: pgsql-hackers
Hiroshi Inoue wrote:
> 
> >
> > if someone is waiting for lock then we must not take them
> > into account (and skip to check for conflicts with lock
> > holders) if
> >
> > 1. we already has lock with >= priority (currently, more
> >    restrictive locks have greater priority);
> > or
> > 2. lock requested doesn't conflict with lock of any waiters;
> 
> Does this mean that the lock has a low priority ?  If so,this

Yes and no -:)

If we acquire ShareLock (prio 4) and someone with RowShareLock (2)
is waiting then this means that table is locked in ExclusiveLock
(or AccessExclusiveLock) mode and we'll going to sleep after
lock-holder conflict test (so, we could go to sleep just after 
seeing that our prio is higher, without lock-holder conflict test).

If we acquire RowShareLock and someone with ShareLock is
waiting due to table is locked in RowExclusiveLock mode then
we are allowed to continue: ShareLock waiter will be wakeupd
after releasing of RowExclusiveLock and we don't conflict
with any of these lock mode.

> state(2.) is hardly changed.  When this waiter is wakeupd ?
> 
> > or
> > 3. conflicting waiter is waiting for us: its lock conflicts
> >    with locks we already hold, if any.
> >
> > I foresee that we also will have to change lock queue ordering
> > code but I have to think about it more.
> >
> 
> Do you say about the following stuff in ProcSleep() ?
> 
>         proc = (PROC *) MAKE_PTR(waitQueue->links.prev);
> 
>         /* If we are a reader, and they are writers, skip past them */
>         for (i = 0; i < waitQueue->size && proc->prio > prio; i++)
>                 proc = (PROC *) MAKE_PTR(proc->links.prev);
> 
>         /* The rest of the queue is FIFO, with readers first, writers last */
>         for (; i < waitQueue->size && proc->prio <= prio; i++)
>                 proc = (PROC *) MAKE_PTR(proc->links.prev);
> 
> Seems above logic is only for 2 levels of priority(READ/WRITE).
> But it's difficult for me to propose a different design for this.

Yes. I'm not sure how useful is priority logic now.

Keep thinking...

Vadim

In response to

pgsql-hackers by date

Next:From: Herouth MaozDate: 1999-04-29 11:42:18
Subject: Re: [HACKERS] Re: [GENERAL] unknown symbol 'lo_unlink'
Previous:From: Massimo Dal ZottoDate: 1999-04-29 09:28:22
Subject: Re: [HACKERS] How do I get the backend server into gdb?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group