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,
elseother backends * might see a partially-set xid here.    But holding both locks at once * would be a nasty
concurrencyhit (and in fact could cause a * deadlock against GetSnapshotData).  So for now, assume atomicity. * Note
thatreaders 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
PGPROCscouldn'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)