On Fri, May 30, 2008 at 10:40 AM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br
/><divclass="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt
0pt0pt 0.8ex; padding-left: 1ex;"> But since you mention it: one of the plausible answers for fixing the<br /> vacuum
problemfor read-only slaves is to have the slaves push an xmin<br /> back upstream to the master to prevent premature
vacuuming. The current<br /> design of pg_standby is utterly incapable of handling that requirement.<br /> So there
mightbe an implementation dependency there, depending on how<br /> we want to solve that problem.<br
/></blockquote></div><br/>I think it would be best to not make the slave interfere with the master's operations; that's
onlygoing to increase the operational complexity of such a solution.<br /><br />There could be multiple slaves
followinga 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.<br /><br />I don't think any
oneinstallation would see all of the above mentioned scenarios, but we need to take care of multiple slaves operating
offof a single master; something similar to cascaded Slony-I.<br /><br />My two cents.<br /><br />Best regards,<br />--
<br/>gurjeet[.singh]@EnterpriseDB.com<br />singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com<br /><br
/>EnterpriseDB<a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br /><br />Mail sent from my
BlackLaptopdevice
