Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.de> 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
