Re: Multiple Xids in PGPROC? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Multiple Xids in PGPROC?
Date
Msg-id 8461.1083781096@sss.pgh.pa.us
Whole thread Raw
In response to Multiple Xids in PGPROC?  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: Multiple Xids in PGPROC?  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Re: Multiple Xids in PGPROC?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: ALTER TABLE TODO items
Next
From: Richard Huxton
Date:
Subject: Re: PostgreSQL pre-fork speedup