Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I'm not sure you can expect that to work. The system is not built to
guarantee instantaneous response to mode changes like that.
Um, as long as xlog writing stops immediate recycling when
pg_start_backup is executed everything should be fine, since archived
logs are not expected to be present until pg_stop_backup is done.
Wrong. You forgot about all the *other* behaviors that change depending
on XLogArchivingActive, like whether CREATE INDEX gets archived or
just fsync'd. I don't think it makes sense for CREATE INDEX to change
that behavior in midstream, even assuming that it noticed the flag
change instantly.
Ok, but how can I recognize whether all running commands have safely
switched to "archiving mode" after enabling it, to continue backing up?
Thought a little about your proposal to use a non-copying
archive_command, since I only want to have a backup of the state the
cluster had when backup started, but this won't work because all write
actions that are not appending (truncate, drop) would remove files
needed for pre-backup state while possibly not backed up yet, thus the
WAL archive is needed.
Following your proposal, I could redirect archiving to /dev/null while
not backing up, but how can I make sure that WAL files of transactions,
open when starting the backup procedure, are written to the wal
directory, not lost previously? When pg_start_backup() is executed, I'd
need the archiver to write all "hot" xlog files again.
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
