Re: Multiple Xids in PGPROC?

On Wed, May 05, 2004 at 02:18:16PM -0400, Tom Lane wrote:
> Manfred Koizar <mkoi-pg@aon.at> writes:

> >  .  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.

There is a comment in varsup.c, GetNewTransactionId():

	 * XXX by storing xid into MyProc without acquiring SInvalLock, we are
	 * relying on fetch/store of an xid to be atomic, else other backends
	 * might see a partially-set xid here.	But holding both locks at once
	 * would be a nasty concurrency hit (and in fact could cause a
	 * deadlock against GetSnapshotData).  So for now, assume atomicity.
	 * Note that readers of PGPROC xid field should be careful to fetch
	 * the value only once, rather than assume they can read it multiple
	 * times and get the same answer each time.
	 *
	 * A solution to the atomic-store problem would be to give each PGPROC
	 * its own spinlock used only for fetching/storing that PGPROC's xid.
	 * (SInvalLock would then mean primarily that PGPROCs couldn't be added/
	 * removed while holding the lock.)


I think if we want to do nontrivial manipulations in PGPROC we should
make sure it's properly locked.  Maybe it's a good time to implement the
locking suggested here?  With a LWLock instead of a spinlock, of course;
we would need MaxBackends extra LWLocks.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Tiene valor aquel que admite que es un cobarde" (Fernandel)