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: | 37268277.73E1B8BF@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
DeadLockCheck().
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-04-28 03:56:49 | Re: [HACKERS] Lock freeze ? in MVCC |
Previous Message | Thomas Lockhart | 1999-04-28 03:25:15 | Re: [HACKERS] numeric data type on 6.5 |