Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
>> On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
>>
>>> It strikes me that allowing archive_command to be changed on the fly
>>> might not be such a good idea though, or at least it shouldn't be
>>> possible to flip it from empty to nonempty during live operation.
>>>
>
>
>> I'd rather fix it the proposed way than force a restart. ISTM wrong to
>> have an availability feature cause downtime.
>>
>
> I don't think that people are very likely to need to turn archiving on
> and off on-the-fly. Your proposed solution introduces a great deal of
> complexity (and risk of future bugs-of-omission, to say nothing of race
> conditions) to solve a non-problem. We have better things to be doing
> with our development time.
>
So how to do a file based backup without permanent archiving? If
pg_start_backup would turn on archiving temporarily with forcing
archiving all WAL files that contain open transactions, this would be
possible. This is what's requested for sites where PITR isn't needed,
just filesystem level backup. Currently, this can be mimicked somehow by
turning on archiving on-the-fly, hoping that all xactions are in the WAL
archive when pg_start_backup is issued (Simons mail shows how this will
fail).
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
