On Wed, Dec 29, 2010 at 20:19, Gurjeet Singh <singh.gurj...@gmail.com> wrote: > On Wed, Dec 29, 2010 at 1:42 PM, Robert Haas <robertmh...@gmail.com> wrote: >> >> On Dec 29, 2010, at 1:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > Is it really stable enough for bin/? My impression of the state of >> > affairs is that there is nothing whatsoever about replication that >> > is really stable yet. >> >> Well, that's not stopping us from shipping a core feature called >> "replication". I'll defer to others on how mature pg_streamrecv is, but if >> it's no worse than replication in general I think putting it in bin/ is the >> right thing to do. > > As the README says that is not self-contained (for no fault of its own) and > one should typically set archive_command to guarantee zero WAL loss.
Yes. Though you can combine it fine with wal_keep_segments if you think that's safe - but archive_command is push and this tool is pull, so if your backup server goes down for a while, pg_streamrecv will get a gap and fail. Whereas if you configure an archive_command, it will queue up the log on the master if it stops working, up to the point of shutting it down because of out-of-disk. Which you *want*, if you want to be really sure about the backups. > <quote> > TODO: Document some ways of setting up an archive_command that works well > together with pg_streamrecv. > </quote> > > I think implementing just that TODO might make it a candidate. Well, yes, that's obviously a requirement. > 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. It's not that much code, but some more eyes on it would always be good! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers