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

From Simon Riggs
Subject Re: Interaction of PITR backups and Bulkoperationsavoiding WAL
Date
Msg-id 1173459439.3641.291.camel@silverbirch.site
Whole thread Raw
In response to Re: Interaction of PITR backups and Bulk operationsavoiding WAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Interaction of PITR backups and Bulkoperationsavoiding WAL  ("Jim C. Nasby" <jim@nasby.net>)
Re: Interaction of PITR backups and Bulkoperationsavoiding WAL  (Bruce Momjian <bruce@momjian.us>)
Re: Interaction of PITR backups and Bulkoperationsavoiding WAL  (Bruce Momjian <bruce@momjian.us>)
Re: Interaction of PITR backups and Bulkoperationsavoiding WAL  (Bruce Momjian <bruce@momjian.us>)
Re: Interaction of PITR backups and Bulkoperationsavoiding WAL  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, 2007-03-09 at 11:47 -0500, 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.

It's certainly a quicker fix. Unless others object, I'll set
archive_command to only be changeable at server startup.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: CLUSTER and MVCC
Next
From: Andreas Pflug
Date:
Subject: Re: Interaction of PITR backups and Bulk operationsavoiding WAL