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

Re: [HACKERS] Lock freeze ? in MVCC

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Inoue(at)tpf(dot)co(dot)jp, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Lock freeze ? in MVCC
Date: 1999-04-28 03:37:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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


In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 1999-04-28 03:56:49
Subject: Re: [HACKERS] Lock freeze ? in MVCC
Previous:From: Thomas LockhartDate: 1999-04-28 03:25:15
Subject: Re: [HACKERS] numeric data type on 6.5

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