Re: locking problems

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

In response to

Responses

Browse pgsql-general by date

  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 ?