Re: [HACKERS] Lock freeze ? in MVCC

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().

Vadim