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-25 16:24:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>>Tom Lane wrote:
>>>This is silly.  Why not just turn archiving on and off?
>>Not quite. I want online backup, but no archiving. 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 don't get to count the edit/SIGHUP steps, because those would be the
> same for any other GUC.

That's right, but my proposal would implicitely switch on archiving 
while backup is in progress, thus explicitely enabling/disabling 
archiving wouldn't be necessary.
> AFAICS you could get the effect by setting up an archive_command script
> 	sleep 100
> 	exit 1
> so that the archiver will do nothing.

Doesn't WAL expect the WAL files already archived to be recyclable, so 
they could get overwritten in the pg_xlog dir while backup is running? 
Additionally, the doc recommends omitting pg_xlog from the file level 
backup, so a restart would need the archived wal files, no?

> BTW, I don't actually understand why you want this at all.  If you're
> not going to keep a continuing series of WAL files, you don't have any
> PITR capability.  What you're proposing seems like a bulky, unportable,
> hard-to-use equivalent of pg_dump.  Why not use pg_dump?

Because pg_dump will take too long and create bloated dump files. All I 
need is a physical backup for disaster recovery purposes without 
bringing down the server.

In my case, I'd expect a DB that uses 114GB on disk to consume 1.4TB 
when pg_dumped, too much for the available backup capacity (esp. 
compared to net content, about 290GB). See other post "inefficient bytea 
escaping" for details.


In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-05-25 16:48:22
Subject: Re: Gborg and pgfoundry
Previous:From: Andreas PflugDate: 2006-05-25 16:16:52
Subject: Inefficient bytea escaping?

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