max_standby_delay considered harmful
in [PgSql]
|
Prev: Further Hot Standby documentation required
Next: [HACKERS] Streaming replication - unable to stop the standby
From: Tom Lane on 4 May 2010 19:33 Greg Smith <greg(a)2ndquadrant.com> writes: > If the standby is not current, you may not want people to execute > queries against it. In some situations, returning results against > obsolete data is worse than not letting the query execute at all. As I > see it, the current max_standby_delay implementation includes the > expectation that the results you are getting are no more than > max_standby_delay behind the master, presuming that new data is still > coming in. If the standby has really fallen further behind than that, > there are situations where you don't want it doing anything but catching > up until that is no longer the case, and you especially don't want it > returning stale query data. That is very possibly a useful thing to be able to specify, but the current implementation has *nothing whatsoever* to do with making such a guarantee. It will only kill queries that are creating a lock conflict. I would even argue that it's a bad thing to have a parameter that looks like it might do that, when it doesn't. regards, tom lane -- 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: Josh Berkus on 4 May 2010 19:34 On 5/4/10 4:26 PM, Greg Smith wrote: > > Not the database's problem to worry about. Document that time should be > carefully sync'd and move on. I'll add that. 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. -- -- 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: "Joshua D. Drake" on 4 May 2010 19:51 On Tue, 2010-05-04 at 16:34 -0700, Josh Berkus wrote: > On 5/4/10 4:26 PM, Greg Smith wrote: > > > > Not the database's problem to worry about. Document that time should be > > carefully sync'd and move on. I'll add that. > > 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. +1 Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- 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 Smith on 4 May 2010 20:21 Josh Berkus wrote: > 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. If that's your criteria, 9.0 has already failed that goal. Just the fact that you have to make your own base backup and manage that whole area alone excludes "simple" as a goal anyone can claim 9.0 meets with a straight face, long before you get to the mechanics of how HS handles query cancellation. The new replication oriented features are functional, but neither are close to simple yet. Based on the complication level of replication in other database products, I wouldn't put money on that even being possible. You can make a simpler path the default one, but the minute you want to support more than one use case the complexity involved in setting up replication explodes. Anyway, I have no idea where the idea that recommending time synchronization is a somehow a "high end" requirement, given that every OS I'm aware of makes that trivial nowadays. Slave servers that drift too far away from the master time are going to cause all sorts of problems for user apps too. Any app that gauges how long ago something happened by comparing a database timestamp with now() is going to give misleading results for example, and I know I see those all the time. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.us -- 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: Tom Lane on 4 May 2010 20:31
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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |