Re: Point in Time Recovery

From: SAKATA Tetsuo <sakata(dot)tetsuo(at)lab(dot)ntt(dot)co(dot)jp>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Point in Time Recovery
Date: 2004-07-15 01:49:21
Message-ID: 40F5E2A1.7080908@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers pgsql-patches

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.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Christopher Browne 2004-07-15 02:44:52 Re: Secure DB Systems - How to
Previous Message Mark Kirkwood 2004-07-15 01:43:38 Re: [HACKERS] Point in Time Recovery

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-07-15 02:02:16 Re: Point in Time Recovery
Previous Message Christopher Kings-Lynne 2004-07-15 01:47:37 Re: Release planning (was: Re: Status report)

Browse pgsql-patches by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-07-15 03:21:19 Re: Better fixes for pg_dump bugs
Previous Message Mark Kirkwood 2004-07-15 01:43:38 Re: [HACKERS] Point in Time Recovery