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)
