On Wed, Jan 30, 2013 at 3:13 PM, Adrian Klaver <adrian.klaver@xxxxxxxxx> wrote: > On 01/30/2013 11:16 AM, Jeff Janes wrote: >> >> On Wed, Jan 30, 2013 at 12:58 AM, Neil Worden <nworden1234@xxxxxxxxx> >> wrote: >> >> >>> If not, how do i prevent files from being overwritten when using an >>> archive_command ? >> >> >> It is the archive_command's job to refuse to overwrite. From the docs: >> >> "It is advisable to test your proposed archive command to ensure that >> it indeed does not overwrite an existing file, and that it returns >> nonzero status in this case" >> >> Hopefully you have done this, otherwise bad things may happen when the >> 6D line collides with the 8D line. >> >> If your command does overwrite, then the server currently emitting the >> 8D files will become unrecoverable once those files start getting >> overwritten. If it refuses to overwrite, but returns a zero status, >> then the server currently emitting 6D would become unrecoverable once >> it reaches 8D and its "archived" files are not actually being archived >> but are getting deleted from the local pg_xlog anyway. > > > Would it not be easier to archive the different servers to different > directories and eliminate the possibility of name collision between servers? Easier? I would say that that is the only sane way of doing it. I was pointing out the consequences of messing it up. A proper archive_command will save you from some self-inflicted disasters, but that does not mean I'm recommending that you should invite those disasters on yourself. If the original author is in a production environment, he desperately needs to figure out what is going on, especially so if archive_command is not tested and verified to obey its contract. Cheers, Jeff -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
