Skip site navigation (1) Skip section navigation (2)

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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
Date: 2010-01-23 20:28:00
Message-ID: 1264278481.26222.7.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Sat, 2010-01-23 at 17:35 +0000, Greg Stark wrote:
> On Sat, Jan 23, 2010 at 4:37 PM, Simon Riggs <sriggs(at)postgresql(dot)org> wrote:
> > max_standby_delay = -1 option removed to prevent deadlock.
> 
> This seems unacceptable to me. It means it's impossible to configure a
> reporting slave so it doesn't spuriously signal errors if your reports
> run too long.
> 
> Recall that I am still of the opinion that the only reasonable default
> value for this parameter is actually -1. I don't think we should
> signal errors for correctly working systems unless the user requests
> them in some way.

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.

Lots of things still on the TODO, if you are looking for a project.
http://wiki.postgresql.org/wiki/Hot_Standby_TODO

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: James William PyeDate: 2010-01-23 20:28:18
Subject: Re: plpython3
Previous:From: Andrew DunstanDate: 2010-01-23 20:12:26
Subject: Re: commit fests

pgsql-committers by date

Next:From: Simon RiggsDate: 2010-01-23 20:39:53
Subject: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
Previous:From: Greg StarkDate: 2010-01-23 17:35:28
Subject: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group