Re: Nested transactions RFC

Tom Lane wrote:
>
> Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> > A *stack* of _active_ transaction numbers is not sufficient, we need
> > the whole *tree* of _all_ transactions belonging to the current top
> > level transaction. This is, want I wanted to model in my pg_subtrans
> > "table". And pg_subtrans cannot be a private structure, because it
> > has to be inspected by other transactions too (cf. example above).
>
> Hmm. This seems to me to be vastly overdesigning the feature. I've
> never yet seen a practical application for more than one level of
> subtransaction, so I question whether we should buy into a substantially
> more complex implementation to support the more general case.

I'm for Manfred with this point. I would never suppose
that nested transactions supports only 1 level.

>
> > Is this really related to subtransactions? The current behaviour is,
> > that an error not only aborts the offending command, but the whole
> > (top level) transaction. My proposal doesn't change anything
> > regarding this.
>
> Every single application that I've seen for subtransactions is all about
> error recovery. If we don't fix that then there's no point.

The problem exists with any implementation.
Though tuple validity checking may be only a small part
(I don't think so), I've never seen such proposal other
than Manfred's one.

If I remember correctly, savepoints functionality
was planned for 7.0 but probably we wouldn't have
it in 7.3. The TODO may be a TODO for ever unless
the direction to solve the TODO is decided.

1) without UNDO for individual tuples.
2) with UNDO for individual tuples under no
overwriting smgr.
3) UNDO under overwriting smgr.

regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/