On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
