Re: [HACKERS] Lock freeze ? in MVCC - Mailing list pgsql-hackers

[Charset koi8-r unsupported, filtering to ASCII...]
> Bruce Momjian wrote:
> > 
> > >
> > > 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...
> > >
> > > Bruce, what do you think?
> > 
> > This sounds correct.  I thought I needed to have the queue ordering
> > changed so that row-level locks are queued before table-level locks,
> > because there could be cases of lock escalation from row-level to
> > table-level.
> > 
> > However, it seems the problem is that readers don't share locks if
> > writers are waiting.  With table-level locks, you never escalated a read
> > lock because you had already locked the entire table, while now you do.
> > Perhaps we can tell the system not to share read locks unless you are
> > sharing your own lock due to a lock escalation.
> 
> There is no row-level locks: all locks over tables are
> table-level ones, btree & hash use page-level locks, but
> never do page->table level lock escalation.
> 
> However, I'm not sure that proposed changes will help in the next case:
> 
> session-1 => begin;
> session-1 => insert into tt values (1);    --RowExclusiveLock
> 
> session-2 => begin;
> session-2 => insert into tt values (2);    --RowExclusiveLock
> 
> session-3 => begin;
> session-3 => lock table tt;            --AccessExclusiveLock
>                 (conflicts with 1 & 2)
>                                 ^
> session-1 => lock table tt in share mode;    --ShareLock
>                 (conflicts with 2 & 3)
>                                     ^
> This is deadlock situation and must be handled by
> DeadLockCheck().

OK, I think the problem with the code is that I am preventing a process
from getting a lock if there is a process of higher priority waiting(a
writer).

However, I never check to see if the current process already holds some
kind of lock on the table.  If I change the code so this behaviour will
be prevented if the process already holds a lock on the table, would
that fix it?  In fact, maybe I should always allow it to get the lock if
it holds any other locks.  This should prevent some deadlocks.  It would
put processes at the end of the queue only if they already have no
locks, which I think makes sense, because putting him at the end of the
queue means all his locks are kept while he sits in the queue.

Comments?  The fix would be easy, and I think it would make sense.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026