Re: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin. - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
Date
Msg-id 1264409377.13571.43.camel@ebony
Whole thread Raw
In response to Re: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Leonardo F
Date:
Subject: Re: About "Our CLUSTER implementation is pessimal" patch
Next
From: Simon Riggs
Date:
Subject: Re: default_language