From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Sullivan <andrew(at)libertyrms(dot)info> |
Cc: | PostgreSQL general list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: locking problems |
Date: | 2002-03-19 15:55:37 |
Message-ID: | 29291.1016553337@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andrew Sullivan <andrew(at)libertyrms(dot)info> writes:
> The docs say that if something is locked, the system waits
> deadlock_timeout milliseconds before trying to discover whether the
> condition can ever become unlocked. I ran into a problem with
> deadlocks under heavy load once, and discovered that setting
> deadlock_timeout higher did just what the docs suggested: "Ideally
> the setting should exceed your typical transaction time, so as to
> improve the odds that the lock will be released before the waiter
> decides to check for deadlock." Maybe that's your problem, too.
AFAIK changing deadlock_timeout cannot introduce or remove deadlock
failures. It's purely an efficiency consideration, ie, how much
time is wasted on useless deadlock checks (useless because they find
no deadlock condition), vs how soon you find out about it when you
really do have a deadlock.
Jonathan's problem evidently is a genuine deadlock, and as such
twiddling deadlock_timeout isn't gonna help him. But he hasn't given
enough detail about what he's doing to let anyone understand why he's
hitting a deadlock.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Peltonen | 2002-03-19 15:59:29 | pq_recvbuf: unexpected EOF on client connectoin |
Previous Message | Doug McNaught | 2002-03-19 15:53:38 | Re: Reference pg_user ? |