<div dir="ltr"><div class="gmail_quote">On Wed, Dec 29, 2010 at 1:42 PM, Robert Haas <span dir="ltr"><<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="margin:0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Dec
29,2010, at 1:01 PM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /> > Is it
reallystable enough for bin/? My impression of the state of<br /> > affairs is that there is nothing whatsoever
aboutreplication that<br /> > is really stable yet.<br /><br /></div>Well, that's not stopping us from shipping a
corefeature called "replication". I'll defer to others on how mature pg_streamrecv is, but if it's no worse than
replicationin general I think putting it in bin/ is the right thing to do.</blockquote></div><br />As the README says
thatis not self-contained (for no fault of its own) and one should typically set archive_command to guarantee zero WAL
loss.<br/><br /><quote><br />TODO: Document some ways of setting up an archive_command that works well together
withpg_streamrecv.<br /> </quote><br /><br /> I think implementing just that TODO might make it a
candidate.<br/><br /> I have neither used it nor read the code, but if it works as advertised then it is definitely
a+1 from me; no preference of bin/ or contrib/, since the community will have to maintain it anyway.<br /><br
/>Regards,<br/>-- <br />gurjeet.singh<br />@ EnterpriseDB - The Enterprise Postgres Company<br /><a
href="http://www.EnterpriseDB.com">http://www.EnterpriseDB.com</a><br/><br />singh.gurjeet@{ gmail | yahoo }.com<br
/>Twitter/Skype:singh_gurjeet<br /><br />Mail sent from my BlackLaptop device<br /></div>