On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sat, 2010-01-23 at 21:40 +, Greg Stark wrote:
On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
What is your proposed way of handling buffer pin deadlocks? That will be
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
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
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
Simon Riggs wrote:
It's clearly a
lower priority than other code based upon feedback from the Hot Standby
user group.
What's the the Hot Standby user group?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
On Mon, 2010-01-25 at 16:22 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
It's clearly a
lower priority than other code based upon feedback from the Hot Standby
user group.
What's the the Hot Standby user group?
A group of people who have an interest in using Hot Standby, as
A group of people who have an interest in using Hot Standby, as
advertised on postgresql.org and Weekly News.
There are pg users who won't be using HS/SR? ;-)
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Simon Riggs wrote:
On Sat, 2010-01-23 at 21:40 +, Greg Stark wrote:
On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs si...@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
On Sat, Jan 23, 2010 at 4:37 PM, Simon Riggs sri...@postgresql.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
On Sat, 2010-01-23 at 17:35 +, Greg Stark wrote:
On Sat, Jan 23, 2010 at 4:37 PM, Simon Riggs sri...@postgresql.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
On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs si...@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
On Sat, 2010-01-23 at 21:40 +, Greg Stark wrote:
On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs si...@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
12 matches
Mail list logo
