Re: Interaction of PITR backups and Bulk operationsavoiding WAL

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interaction of PITR backups and Bulk operationsavoiding WAL
Date: 2007-03-09 17:02:21
Message-ID: 45F1931D.20200@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Csaba Nagy 2007-03-09 17:06:47 Re: Interaction of PITR backups and Bulk operationsavoiding WAL
Previous Message Simon Riggs 2007-03-09 16:57:18 Re: Interaction of PITR backups and Bulkoperationsavoiding WAL