From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Interaction of PITR backups and Bulk operationsavoiding WAL |
Date: | 2007-03-09 16:33:11 |
Message-ID: | 1173457991.3641.287.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > Say you issue COPY, CREATE INDEX etc..
> > pg_start_backup()
> > pg_stop_backup()
> > ...then bulk operation ends.
> > This will result in a base backup that does not contain the data written
> > during the bulk operation and the changes aren't in WAL either.
>
> Uh, no. The state of XLogArchivingActive() isn't affected by that.
Sorry, error case should have been
Say you issue COPY, CREATE INDEX etc..
set archive_command
pg_ctl reload
pg_start_backup()
pg_stop_backup()
...then bulk operation ends.
> 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.
As long as we allow it to be turned on/off during normal operation then
there is a current window of error.
I'd rather fix it the proposed way than force a restart. ISTM wrong to
have an availability feature cause downtime.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-09 16:36:29 | Re: CLUSTER and MVCC |
Previous Message | Heikki Linnakangas | 2007-03-09 16:27:40 | Re: CLUSTER and MVCC |