Обсуждение: pgsql/src/backend/storage/lmgr (lmgr.c lock.c proc.c README)

  Date: Thursday, December 21, 2000 @ 19:51:54
Author: tgl

Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/storage/lmgr
     from hub.org:/home/projects/pgsql/tmp/cvs-serv58115/src/backend/storage/lmgr

Modified Files:
    lmgr.c lock.c proc.c README

-----------------------------  Log Message  -----------------------------

Revise lock manager to support "session level" locks as well as "transaction
level" locks.  A session lock is not released at transaction commit (but it
is released on transaction abort, to ensure recovery after an elog(ERROR)).
In VACUUM, use a session lock to protect the master table while vacuuming a
TOAST table, so that the TOAST table can be done in an independent
transaction.

I also took this opportunity to do some cleanup and renaming in the lock
code.  The previously noted bug in ProcLockWakeup, that it couldn't wake up
any waiters beyond the first non-wakeable waiter, is now fixed.  Also found
a previously unknown bug of the same kind (failure to scan all members of
a lock queue in some cases) in DeadLockCheck.  This might have led to failure
to detect a deadlock condition, resulting in indefinite waits, but it's
difficult to characterize the conditions required to trigger a failure.

> -----Original Message-----
> From: tgl@postgresql.org
> Sent: Friday, December 22, 2000 9:52 AM
> To: pgsql-committers@postgresql.org
> Subject: [COMMITTERS] pgsql/src/backend/storage/lmgr (lmgr.c lock.c
> proc.c README)
>
> -----------------------------  Log Message  -----------------------------
>
> Revise lock manager to support "session level" locks as well as
> "transaction
> level" locks.

[snip]

> I also took this opportunity to do some cleanup and renaming in the lock
> code.  The previously noted bug in ProcLockWakeup, that it
> couldn't wake up
> any waiters beyond the first non-wakeable waiter, is now fixed.

I've just noticed that this changed a locking behabior.
For example, VACUUM could hardly acquire the lock
while other backends frequently access the target table.

Regards.
Hiroshi Inoue

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> The previously noted bug in ProcLockWakeup, that it
>> couldn't wake up
>> any waiters beyond the first non-wakeable waiter, is now fixed.

> I've just noticed that this changed a locking behabior.
> For example, VACUUM could hardly acquire the lock
> while other backends frequently access the target table.

Maybe so, but the old behavior was deadlock-prone.  There are cases
in which you *must* wake up a process that's behind non-wakable
processes, or you will have a silent lockup.  I've forgotten the
details, but I demonstrated such a case to myself while I was fixing
this code (I think it took four processes altogether, and two different
locks, to exhibit the problem).

HandleDeadlock is also willing to wake up processes that are not the
first in their queue, so there'd be no guarantee of first-in-first-out
even if we reverted ProcLockWakeup to the deadlock-prone behavior.

Possibly we could arrange for ProcLockWakeup to perform a
HandleDeadlock-like algorithm to determine whether there will be a
deadlock if it stops without waking anyone.  I don't understand
HandleDeadlock well enough to know what it would take to apply it
to this case.

BTW, where did the HandleDeadlock algorithm come from?  It looks to me
like the kind of code that is certainly wrong unless you have a proof
that it's right.  I want to see a paper proving that this algorithm
is right ...

            regards, tom lane