Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> 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.
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
