Re: pgsql/src/backend/storage/lmgr (lmgr.c lock.c proc.c README)

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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