I agree that TimeStamp creates an overhead, but I just want to know if an
accidental update happened to a table and this incident got traced three
days after, what facility PGSQL provide to bring the table to its original
condition. You can't wait regretting on why you did not run ROLLBACK before
COMMIT. (Correct me. I am only a user).

When talking about Oracle's technology and that it creates overhead, it is
true, Oracle's database is not for ordinary machines. You can't expect
performance on a normal 256 MB machine with Oracle. But still the more the
options of recovery the best for mission critical environments.

The feature of enabling/disabling TimeStamp logging is acceptable. A user
must be able to decide whether FlashBack type option is needed or not. In
Oracle 10g we can switch off "FlashBack" feature if we are low on resources.
If PGSQL is to be used in a mission-critical situation then no company will
rely on low-end machines. For these type of situations best environment is
chosen and I think PGSQL must have this type of recovery options. PGSQL
installer can ask the user during setup to enable/disable TimeStamp Logging.

Restoring the database from a backup file that was created three days ago is
not feasible. The changes in other tables and the new things created need to
be done again at the price of just undoing the last update on a particular

Warren Turkal-5 wrote:
> On Saturday 17 February 2007 07:49, RPK wrote:
>> PostgreSQL, already a mature database, needs to have more options for
>> recovery as compared to proprietary databases. I just worked with
>> Oracle's
>> FlashBack query feature in Oracle 9i and FlashBack Table feature in 10g.
>> Future versions of PostgreSQL must have similar features which enable
>> users
>> to bring Table(s) and/or Database(s) to a desired Time Stamp.
> Check out my proposal[1] for Temporal extensions. Ultimately, creating
> valid 
> time and transaction time tables would be possible through my proposal.
> Please 
> check it out.
> [1]http://archives.postgresql.org/pgsql-hackers/2007-02/msg00540.php
> wt
> -- 
> Warren Turkal (w00t)
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

View this message in context: 
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to