From: | Theo Schlossnagle <jesus(at)omniti(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Theo Schlossnagle <jesus(at)omniti(dot)com> |
Subject: | xlogdump fixups and WAL log question. |
Date: | 2006-10-20 17:18:04 |
Message-ID: | 8BC09726-CF44-4DFD-B00D-210D0AE45A3D@omniti.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Not sure who cares, so xzilla indicated I should drop a note here. I
just made the xlogdump stuff work for 8.1 (trivial) and fixed a few
other small issues that caused it to not work right both generally
and in our environment.
http://pgfoundry.org/tracker/index.php?
func=detail&aid=1000760&group_id=1000202&atid=772
We're using it to track down what's causing some wal log ruckus.
We're generating about a quarter terabyte of WAL logs a day (on bad
days) which is posing some PITR backup pains. That amount isn't a
severe challenge to backup, but our previous install was on Oracle
and it generated substantially less archive redo logs (10-20 gigs per
day).
Is it possible to create tables in fashion that will not write info
to the WAL log -- knowingly and intentionally making them
unrecoverable? This is very desirable for us. We snapshot tables
from a production environment. If the database goes down and we
recover, the old snapshots are out of date anyway and serve no useful
purpose. The periodic snapshot procedure would re-snap them in short
order anyway. I'd like to do:
INSERT INTO TABLE tblfoo_snap1 AS SELECT * from <table on remote
database> NO LOGGING;
(NO LOGGING being the only part we're currently missing) Is something
like this possible?
Cheers ;-)
Theo
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-10-20 17:54:51 | zic with msvc |
Previous Message | mark | 2006-10-20 17:11:16 | Re: [SPAM?] Re: Asynchronous I/O Support |