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'll look at the buffer pin deadlock problem again, but I didn't
> realize the situation was so dire. And what were the downsides of the
> "stop gap"?
Any query that attempted to wait for a lock threw an ERROR.
Since the -1 setting would never resolve a deadlock itself, if we
allowed it we would have to either use the stop gap or use a full
deadlock detector.
Given the stop gap does what -1 says it will never do, ISTM that having
-1 would be contradictory. I did not wish to remove it, but it seemed
safer to do so. Putting it back is straightforward, if it makes sense.
We would need to detect deadlock from both directions, when Startup
begins to wait when users sleep and when users begin to wait when
Startup sleeps. Full deadlock detection is to much code for too small a
problem.
-- Simon Riggs www.2ndQuadrant.com
