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
> 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
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 1999-04-28 03:56:49|
|Subject: Re: [HACKERS] Lock freeze ? in MVCC|
|Previous:||From: Thomas Lockhart||Date: 1999-04-28 03:25:15|
|Subject: Re: [HACKERS] numeric data type on 6.5|