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.  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: xlogdump fixups and WAL log question.  ("Simon Riggs" <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: mark@mark.mielke.cc
Дата:
Сообщение: Re: [SPAM?] Re: Asynchronous I/O Support
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: [SPAM?] Re: Asynchronous I/O Support