Simon Riggs wrote:
On Thu, 2006-05-25 at 17:25 +0200, Andreas Pflug wrote:
Currently, I have to
edit postgresql.conf and SIGHUP to "turn on archiving" configuring a
(hopefully) writable directory, do the backup, edit postgresql.conf and
SIGHUP again. Not too convenient...
You're doing this for pgAdmin right?
Not yet, just trying to manage a server.
My understanding was that we had the tools now to edit the
postgresql.conf programmatically?
Seems like its not too convenient to change the way the server operates
to do this, as long as we solve the SIGHUP/postgresql.conf problem. I'm
also not that happy about curtailing people's options on backup either:
if people decided they wanted to have a mixture of isolated on-line
backup (as you suggest), plus active archiving at other times they would
still have the problems you suggest.
Why?
My suggestion is to redefine XLogArchivingActive. Currently, it tests
for non-null archive_command. I propose
bool XlogArchivingActive()
{
if (XLogArchiveCommand[0] == 0)
return false;
return (XLogPermanentArchive // from GUC
|| OnlineBackupRunning()); // from pg_start_backup
}
The people you mention simply have XLogPermanentActive=true in
postgresql.conf, delivering the current behaviour.
Not sure what the edit commands are offhand, but we would need the
following program:
- edit postgresql.conf
- pg_reload_conf()
- wait 30
- pg_start_backup('blah')
- backup
- pg_stop_backup()
- unedit postgresql.conf
- pg_reload_conf()
Which could then be wrapped even more simply as
- pg_start_backup_online('blah')
- backup
- pg_stop_backup_online()
Editing postgresql.conf for this is ugly. In addition,
pg_start_backup_online would need an additional parameter, the (highly
machine specific) archive_command string. I'd like to see that parameter
untouched in postgresql.conf.
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
