Re: Multiple Xids in PGPROC?

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?

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