Re: Interaction of PITR backups and Bulk operationsavoiding WAL - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: Interaction of PITR backups and Bulk operationsavoiding WAL
Date
Msg-id 45F1931D.20200@pse-consulting.de
Whole thread Raw
In response to Re: Interaction of PITR backups and Bulk operationsavoiding WAL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> 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



pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Interaction of PITR backups and Bulkoperationsavoiding WAL
Next
From: Csaba Nagy
Date:
Subject: Re: Interaction of PITR backups and Bulk operationsavoiding WAL