On Fri, 12 Oct 2001, Michael Meskes wrote:
> On Thu, Oct 11, 2001 at 01:09:25PM -0700, Stephan Szabo wrote:
> > Well, it'd be likely to get in this state if the first transaction grabbed
> > any write locks and then sat on them without committing or doing any more
> > commands, since the vacuum would wait on that and the rest of the
> > transactions will probably wait on the vacuum. Is that a possible
> > situation?
>
> Maybe. The first transaction should not sit on any lock, but I have to dig
> through the sources to be sure it really does not. Also I wonder if this
> could happen through normal operation:
>
> Task 1:
>
> begin
> acquire lock in table A
> acquire lock in table B
> commit
>
> Task 2 (vacuum):
>
> lock table B
> lock table A
>
> Could this force the situation too?
Do you mean like task1 has gotten the A lock, and then task 2 gets the B
and then task1 tries to get B and task2 tries to get A? I *think*
(without ever looking at the code, and going on messages from here) that
would probably kick off the deadlock alert since you're trying to grab
a lock from a process which is waiting for a lock you hold.
> If so the easy workaround would be to run vacuum when there is no other
> process accessing the DB.
Well, fortunately it sounds like in 7.2 we'll have much less of this in
the first place since the normal uses of vacuum will be happier with
sharing.