From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Recovery Features |
Date: | 2004-07-10 19:21:40 |
Message-ID: | 1089487299.17493.661.camel@stromboli |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2004-07-10 at 15:04, Jan Wieck wrote:
> On 7/5/2004 6:16 PM, Simon Riggs wrote:
>
> > 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...
>
> IF ... the recovery process would be primary key based, and IF the
> database definitions would allow for balance type field handling (the
> log contains value deltas for balance fields instead of overwriting
> them), THEN this would be a direction I would be looking into.
>
> But as things are, the whole recovery is ctid and binary block based. So
> you would now leave out the ctid based changes to several tuples because
> of belonging to said transaction. Later on, an original whole block
> appears in the WAL and overwrites ... so you get what ... partial
> transactions into the recoverd DB?
>
> >
> > ...Nobody is shouting YES, so its a dodo...
>
> No way!
>
Sorry...I meant "this idea is dead, just like the extinct Dodo bird".-
I've been trying to be succinct, but that has led to information loss.
...you've come up with an even better reason why the idea is not good.
Many thanks,
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-07-10 19:22:17 | Re: [HACKERS] PgSQL 7.4.2 - NaN on Tru64 UNIX |
Previous Message | Alvaro Herrera | 2004-07-10 19:20:32 | Re: Nested Transactions, Abort All |