xlogdump fixups and WAL log question.
От | Theo Schlossnagle |
---|---|
Тема | xlogdump fixups and WAL log question. |
Дата | |
Msg-id | 8BC09726-CF44-4DFD-B00D-210D0AE45A3D@omniti.com обсуждение исходный текст |
Ответы |
Re: xlogdump fixups and WAL log question.
Re: xlogdump fixups and WAL log question. |
Список | 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/
В списке pgsql-hackers по дате отправления: