On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.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