> Oh, now I get it: the point is to prevent Tx Old from exiting the set
> of "still running" xacts as seen by Tx S.  Okay, it makes sense.
> I'll try to add some documentation to explain it.

TIA! I had no time from '99 -:)

> Given this, I'm wondering why we bother with having a separate
> XidGenLock spinlock at all.  Why not eliminate it and use SInval
> spinlock to lock GetNewTransactionId and ReadNewTransactionId?

Reading all MyProc in GetSnashot may take long time - why disallow
new Tx to begin.

> What did you think about reordering the vacuum qual tests and
> AbortTransaction sequence?

Sorry, no time at the moment.

> BTW, I'm starting to think that it would be really nice if we could
> replace our spinlocks with not just a semaphore, but something that has
> a notion of "shared" and "exclusive" lock requests.  For example,
> if GetSnapshotData could use a shared lock on SInvalLock, it'd
> improve concurrency.

Yes, we already told about light lock manager (no deadlock detection etc).

Vadim

Thu, 12 Jul 2001 10:36:30 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Re: Strangeness in xid allocation / snapshot setup 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> Given this, I'm wondering why we bother with having a separate
>> XidGenLock spinlock at all.  Why not eliminate it and use SInval
>> spinlock to lock GetNewTransactionId and ReadNewTransactionId?

> Reading all MyProc in GetSnashot may take long time - why disallow
> new Tx to begin.

Because we need to synchronize?  It bothers me that we're assuming
that fetching/storing XIDs is atomic.  There's no possibility at all
of going to 8-byte XIDs as long as the code is like this.

I doubt that a spinlock per PROC structure would be a better answer,
either; the overhead of getting and releasing each lock would be
nontrivial, considering the small number of instructions spent at
each PROC in these routines.

			regards, tom lane

Thu, 12 Jul 2001 14:37:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: Strangeness in xid allocation / snapshot setup 