On Fri, May 30, 2008 at 10:40 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> But since you mention it: one of the plausible answers for fixing the > vacuum problem for read-only slaves is to have the slaves push an xmin > back upstream to the master to prevent premature vacuuming. The current > design of pg_standby is utterly incapable of handling that requirement. > So there might be an implementation dependency there, depending on how > we want to solve that problem. > I think it would be best to not make the slave interfere with the master's operations; that's only going to increase the operational complexity of such a solution. There could be multiple slaves following a master, some serving data-warehousing queries, some for load-balancing reads, some others just for disaster recovery, and then some just to mitigate human errors by re-applying the logs with a delay. I don't think any one installation would see all of the above mentioned scenarios, but we need to take care of multiple slaves operating off of a single master; something similar to cascaded Slony-I. My two cents. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com EnterpriseDB http://www.enterprisedb.com Mail sent from my BlackLaptop device