max_standby_delay considered harmful
in [PgSql]
|
Prev: Further Hot Standby documentation required
Next: [HACKERS] Streaming replication - unable to stop the standby
From: Josh Berkus on 4 May 2010 20:48 > Releasing a hot standby which *only* works for users with an operational > ntp implementation is highly unrealistic. Having built-in replication > in PostgreSQL was supposed to give the *majority* of users a *simple* > option for 2-server failover, not cater only to the high end. Every > administrative requirement we add to HS/SR eliminates another set of > potential users, as well as adding another set of potential failure > conditions which need to be monitored. To be completely practical, I'm saying that we should apply & test Simon's latest patch moving the delay calculation to be application lag instead of standby lag. I'm also suggesting that we should have a standby lag option for 9.1 (as well as, probably, a "wait forever" option ala Tom's suggestion). -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 4 May 2010 23:06 Tom Lane wrote: > Greg Smith <greg(a)2ndquadrant.com> writes: > > Anyway, I have no idea where the idea that recommending time > > synchronization is a somehow a "high end" requirement, > > Considering that clock skew was only one of several scenarios in which > the max_standby_delay code misbehaves, it's not that important whether > you consider it highly probable or not. The code still needs a > redesign, and we may as well eliminate the assumption of tight > synchronization while we are at it. There's no really good reason to > have that requirement in there. Should I be concerned that we are redesigning HS features at this stage in the release? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 4 May 2010 23:38 On Tue, May 4, 2010 at 11:06 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Should I be concerned that we are redesigning HS features at this stage > in the release? Yep. You can decide whether you want to be concerned by the redesign itself, or by the concerns about the underlying code that are motivating the redesigns, but yes, you should definitely be concerned. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 5 May 2010 00:01 Robert Haas wrote: > On Tue, May 4, 2010 at 11:06 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > >> Should I be concerned that we are redesigning HS features at this stage >> in the release? >> > > Yep. You can decide whether you want to be concerned by the redesign > itself, or by the concerns about the underlying code that are > motivating the redesigns, but yes, you should definitely be concerned. > > > Our process is shot to pieces. But then, we knew that, didn't we ;-) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Stark on 5 May 2010 00:18
On Wed, May 5, 2010 at 5:01 AM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > Our process is shot to pieces. But then, we knew that, didn't we ;-) > Franky I think these kinds of usability questions are things that we'll never have great success getting feedback on without users banging on the system. There are solutions but none of them are perfect. We a) either let releases go out with functionality that nobody's sure users will be happy with and promise that the next release will polish it, b) commit big functionality changes only at the beginning of the release cycle and live with a two-release cycle latency for such changes, or c) make last-minute changes during betas. So far we've seen a combination of (a) and (c). I think (a) has worked out well, sure we have some non-ideal behaviour in new features but people forgive and forget when the later releases polish it. I've always advocated for (b) though, I think we've been lucky with the cases where we've needed last minute adjustments that they've worked better than we had a right to expect. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |