Re: PITR Functional Design v2 for 7.5 - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: PITR Functional Design v2 for 7.5
Date
Msg-id 1078952485.3554.19.camel@fuji.krosing.net
Whole thread Raw
In response to Re: PITR Functional Design v2 for 7.5  (Josh Berkus <josh@agliodbs.com>)
Responses Re: PITR Functional Design v2 for 7.5  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
Josh Berkus kirjutas T, 09.03.2004 kell 19:46:

> In my personal experience, the *primary* use of PITR is recovery from User 
> Error.   For example, with one SQL Server 7.0 installation for a law firm, 
> I've made use of PITR 4 times over the last 4 years: once was because and HDD 
> failed, the other three were all becuase of IT dept. staff running 
> unconstrained UPDATE queries against the back end.   For recovery with 
> minimal loss of data, there are existing solutions, such as replication 
> servers, in addition to PITR; for recovery from User Error, only PITR will 
> suffice.

Actually PostgreSQL used to have very good support for this until some
time in Postgres95 development by supporting additional temporal
qualifiers for queries. I.e. one could ask for 'SELECT SALARY FROM
EMPLOYEES AS IT WAS AT YESTERDAY NOON' (the syntax was not exacly this
:)

It was a very simple and logical result of PostgreSQL's MVCC storage and
was supported by VACUUM allowing dropping only deleted tuples older than
some specified time.

Oracle has recently added something similar (using their WAL's) to ver.
9.0 or 10.x of their DBMS exactly for recovery from user errors.

The support for this was dropped from postgreSQL citing performance
reasons at that time, but I still hope that it can restored some time.

--------------
Hannu


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Slony-I makes progress
Next
From: Andrew Dunstan
Date:
Subject: Re: selective statement logging