Skip site navigation (1) Skip section navigation (2)

Re: XLogArchivingActive

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XLogArchivingActive
Date: 2006-05-26 14:17:08
Message-ID: 44770DE4.8000405@pse-consulting.de (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Regards,
Andreas

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-05-26 14:33:59
Subject: Re: Bug with UTF-8 character
Previous:From: Marko KreenDate: 2006-05-26 14:16:59
Subject: Re: Bug with UTF-8 character

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group