Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2006-05-26 14:33:59|
|Subject: Re: Bug with UTF-8 character |
|Previous:||From: Marko Kreen||Date: 2006-05-26 14:16:59|
|Subject: Re: Bug with UTF-8 character|