Bruce Momjian wrote:
> Tom Lane wrote:
>> Manfred Koizar <mkoi-pg@aon.at> writes:
>> > The straightforward pg_clog lookup is still in transam.c,
>> > but has been deactivated:
>> > * Now this func in shmem.c and gives quality answer by scanning
>> > * PGPROC structures of all running backend. - vadim 11/26/96
>>
>> > What was the motivation for this change? Consistency or speed?
>>
>> Getting the right answer --- the other way can't tell the difference
>> between an open transaction and a crashed one.
>>
>> > . We could include a small number of subtransaction xids in PGPROC.
>>
>> Yeah, I was just thinking that myself. If we only need to show open
>> subtrans xids, then the number you'd need would depend on nesting depth
>> not the total number of subxacts used. So half-a-dozen or so would
>> probably suffice for 99% of situations. You'd need a flag that could be
>> set to show "I'm so deeply nested I can't fit all my subxacts here",
>> but you'd only need to go to pg_subtrans when that happened.
>>
>> On the other hand, I'm not sure how much that helps, considering you
>> probably have to resolve the subtrans XID up to its parent anyway to
>> check commit/abort status.
>
> I am confused. Don't we need to know about all subtransctions, not just
> opened ones?
>
> BEGIN; -- xid=100
> BEGIN; -- xid=101
> COMMIT;
>
> At this point, don't backends need to know the parent of xid 101,
> meaning we can't limit visibility to just the transactions that are
> currently openly nested?
That's right. You can only forget about nested rolled back ones, because
no matter what, their changes will never become valid. But every
committed subtransaction is from the outside still in progress until the
outmost transaction commits/rolls back.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
