Re: Multiple Xids in PGPROC?

On Wed, May 05, 2004 at 02:18:16PM -0400, Tom Lane wrote:
> Manfred Koizar <mkoi-pg(at)aon(dot)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)