Message-ID: <40F5E2A1.7080908@lab.ntt.co.jp>
Date: Thu, 15 Jul 2004 10:49:21 +0900
From: SAKATA Tetsuo <sakata.tetsuo@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP;
	rv:1.4) Gecko/20030718
MIME-Version: 1.0
To: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Point in Time Recovery
References: <200407132242.i6DMgg612564@candle.pha.pa.us>	
	<1089760416.17493.3327.camel@stromboli>	
	<40F49AE9.2060805@familyhealth.com.au>
	<1089789682.17493.3890.camel@stromboli>
In-Reply-To: <1089789682.17493.3890.camel@stromboli>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi, folks.

My colleages and I are planning to test PITR after the 7.5 beta release.
Now we are desinging test items, but some specification are enough clear
(to us).

For example, we are not clear which resouce manager order to store log
records.

   - some access method (like B-tree) require to log its date or not.
   - create/drop action of table space to be stored to the log or not.

We'll be pleased if someone informs them.

The test set we'll proceed has following items;

   - PITR can recover ordinary commited transaction's data.
     - tuple data themselves
     - index data associated with them
   - PITR can recover commited some special transaction's data.
     - DDL; create database, table, index and so on
     - maintenance commands (handling large amount of data);
       truncate, vacuum, reindex and so on.

Items above are 'data aspects' of the test. Other aspects are as follows

   - Place of the archival log's drive;
     PITR can recover a database from archived log data
        - stored in the same drive as xlog.
        - stored in a different drive on the same machine
          in which the PostgreSQL runs.
        - stored in a different drive on a different machine.

   - Duration between a checkpoint and recovery;
     PITR can recover a database enough long after a checkpoint.

   - Time to Recover;
     - to end of the log.
     - to some specified time.

   - Type of failures;
     - system down --- kill the PostgreSQL process (as a simulation).
     - media lost  --- delete database files (as a simulation).
     - These two case will be tested by a simulated situation first,
       and we would try some 'real' failure after.
       (real power down of the test machine to the first case,
        and 'plug off' the disk drive to the second one.
        these action would damage test machine, this is because
        we plan them after 'ordinary' test items.)

The test set is under construction and we'll test the 7.5 beta
for some weeks, and report the result of the test here.

	Sincerely yours.
	Tetsuo SAKATA.

-- 
sakata.tetsuo _at_ lab.ntt.co.jp
SAKATA, Tetsuo. Yokosuka JAPAN.