On Wed, Jan 30, 2013 at 3:13 PM, Adrian Klaver <adrian.klaver@gmail.com> wrote:
> On 01/30/2013 11:16 AM, Jeff Janes wrote:
>>
>> On Wed, Jan 30, 2013 at 12:58 AM, Neil Worden <nworden1234@gmail.com>
>> 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