On Mon, 2010-01-25 at 10:59 +0200, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > Simon Riggs wrote:
> >> On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote:
> >>> Would this simple scheme work:
> >>>
> >>> When the startup process has waited for a short while (ie
> >>> deadlock_timeout), it sends the signal "please check if you're holding a
> >>> pin on buffer X" to all backends. When a backend receives that signal,
> >>> it checks if it is holding a pin on the given buffer *and* waiting on a
> >>> lock. If it is, abort the transaction. Assuming that a backend can only
> >>> block waiting on a lock held by the startup process, deadlock detection
> >>> is as simple as that.
> >> No, it won't work. A deadlock could occur after the startup process has
> >> already been waiting for longer than the deadlock timeout.
> >
> > Retry every deadlock_timeout seconds?
>
> Or better yet, also check if the current backend is holding the
> waited-for pin in CheckDeadLock().
The deadlock can be caused by either party. As long as the check occurs
in both places, it can be done.
The logic for the startup process must be enhanced to allow for both
deadlocks and normal pin buffer checks happening at different times
without confusion. The SIGUSR1 message received by backend would need to
differ as to whether it was a deadlock check timeout or a normal buffer
pin timeout.
It can be done, though will require very careful testing. It's clearly a
lower priority than other code based upon feedback from the Hot Standby
user group. My assessment is too much code, too rare a case and too
little time, so it is a relative, not absolute judgement.
I would not personally argue this is something worth delaying for,
though you and Greg may wish to do that. If you insisted it was me that
did this, I would not be in a position to start it for about 10 days.
-- Simon Riggs www.2ndQuadrant.com