Re: locking problems - Mailing list pgsql-general

From Tom Lane
Subject Re: locking problems
Date
Msg-id 29291.1016553337@sss.pgh.pa.us
Whole thread Raw
In response to Re: locking problems  (Andrew Sullivan <andrew@libertyrms.info>)
Responses Re: locking problems  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-general
Andrew Sullivan <andrew@libertyrms.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

pgsql-general by date:

Previous
From: Doug McNaught
Date:
Subject: Re: Reference pg_user ?
Next
From: Peter Peltonen
Date:
Subject: pq_recvbuf: unexpected EOF on client connectoin