Tom Lane wrote:
>
> Manfred Koizar <[EMAIL PROTECTED]> 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". An
On Sun, 12 May 2002, Tom Lane wrote:
> Manfred Koizar <[EMAIL PROTECTED]> 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_subt
Manfred Koizar <[EMAIL PROTECTED]> 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 pr
Tom,
reading my message again and your response, I see, that some points
were a bit unclear.
On Fri, 10 May 2002 13:12:21 +0200, I wrote:
|if it is acceptable for subtransactions to use up transaction numbers,
Of course, "use up" is nonsense, as it sounds like "use all
available"; this should h
Manfred Koizar <[EMAIL PROTECTED]> writes:
> TransactionId GetParentXact(TransactionId xnum) uses pg_subtrans to
> find the parent transaction of xnum.
This is not only extremely expensive, but in practice would cause
infinite recursion: any attempt to validate the commit state of a
row in pg_sub
Hi,
if it is acceptable for subtransactions to use up transaction numbers,
then here is a half baked RFC for a possible implementation.
If not, forget the rest of this message.
The proposed implementation works much like the current transaction
handling. It needs an additional system table
pg_s
