Re: Multiple Xids in PGPROC?

Tom Lane wrote:
> Manfred Koizar <mkoi-pg(at)aon(dot)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?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073