Re: max_standby_delay considered harmful - Mailing list pgsql-hackers

From Greg Smith
Subject Re: max_standby_delay considered harmful
Date
Msg-id 4BE0B9EE.6070908@2ndquadrant.com
Whole thread Raw
In response to Re: max_standby_delay considered harmful  (Josh Berkus <josh@agliodbs.com>)
Responses Re: max_standby_delay considered harmful
List pgsql-hackers
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@2ndQuadrant.com   www.2ndQuadrant.us



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: max_standby_delay considered harmful
Next
From: Tom Lane
Date:
Subject: Re: max_standby_delay considered harmful