From: | Michael Meskes <meskes(at)postgresql(dot)org> |
---|---|
To: | PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Deadlock? idle in transaction |
Date: | 2001-10-12 08:31:00 |
Message-ID: | 20011012103100.D1945@feivel.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
If so the easy workaround would be to run vacuum when there is no other
process accessing the DB.
Michael
--
Michael Meskes
Michael(at)Fam-Meskes(dot)De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2001-10-12 08:34:09 | Re: Deadlock? idle in transaction |
Previous Message | steve | 2001-10-12 08:24:37 | Re: pg_dump oid problems |