On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sat, 2010-01-23 at 21:40 +0000, Greg Stark wrote:
> >> On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >>> What is your proposed way of handling buffer pin deadlocks? That will be
> >>> acceptable and working to some extent in the next week?
> >>>
> >>> Wait forever isn't always a good idea, anymore, if it ever was.
> >> I've never said it was always a good idea. But killing correctly
> >> running queries isn't always a good idea either. I'm interested in
> >> using HS for running read-only replicas for load balancing. It would
> >> pretty sad if queries dispatched to a read-only replica received a
> >> spurious unpredictable errors for reasons the application programmer
> >> cannot control.
> >
> > I understand your concern and seek to provide the best way forwards in
> > the time available. Hopefully you have a better way, but we can do
> > little about the time. Your input is welcome, and your code also.
>
> I just woke up to this thread too. I have to agree with Greg, we must
> think harder.
Must is a word I would disagree with. There are other bigger usability
issues to resolve at present and I'm not personally going to be
distracted away from addressing them. I have no problem in other
contributions.
> Can you summarize the problem again? I don't immediately see how the
> deadlock could happen.
>
> 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.
Better ideas welcome, but solutions may not be forthcoming in the time
available.
-- Simon Riggs www.2ndQuadrant.com
