From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Recovery Features |
Date: | 2004-07-05 22:16:48 |
Message-ID: | 1089065808.17493.85.camel@stromboli |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2004-07-05 at 22:30, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > ...While recovering, it is very straightforward to simply ignore every
> > record associated with one (or more) transactions. That gives us the
> > ability to recover "all apart from txnid X".
>
> Don't even *think* of going there.
Hmmm... thinking is important, as are differing viewpoints. I value
yours and those of everyone else on this list, hence the post.
> What will happen when transaction Y comes along and wants to modify or
> delete a row that was inserted by X? There's no chance of staying
> consistent.
I did point out this downside...a few sentences down.
**This is awful because: transactions are isolated from each other, but
they also provide changes of state that rely on previous committed
transactions. If you change the past, you could well invalidate the
future. If you blow away a transaction and a later one depends upon it,
then you will have broken the recovery chain and will not be able to
recover to present time.**
Theoretically, this is a disaster area.
Practically, Oracle10g provides similar-ish features...
...Nobody is shouting YES, so its a dodo...
Best regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Holdoway | 2004-07-05 22:27:06 | Security... |
Previous Message | Tom Lane | 2004-07-05 22:13:17 | Re: plperl security |