> >> 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 begi
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Isn't spinlock just a few ASM instructions?... on most platforms...
If we change over to something that supports read vs write locking,
it's probably going to be rather more than that ... right now, I'm
pretty dissatisfied with the performance of our
> > Isn't spinlock just a few ASM instructions?... on most platforms...
>
> If we change over to something that supports read vs write locking,
> it's probably going to be rather more than that ... right now, I'm
> pretty dissatisfied with the performance of our spinlocks under load.
We shouldn'
"Mikheev, Vadim" <[EMAIL PROTECTED]> 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 tim
> 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
> XidGen
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> 1.1 For this case acquiring SInval lock before ReadNewTransactionId()
> changes behavior of Tx Old: it postpones change of Tx Old'
> (and Tx New') MyProc->xid in xact.c:CommitTransaction(), so Tx S
> will see Tx Old as running, ie Tx Old'
> > You forget about Tx Old! The point is that changes made by
> > Tx Old *over* Tx New' changes effectively make those Tx New'
> > changes *visible* to Tx S!
>
> Yes, but what's that got to do with the order of operations in
> GetSnapshotData? The scenario you describe can occur anyway.
Try to
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> You forget about Tx Old! The point is that changes made by Tx Old *over*
> Tx New' changes effectively make those Tx New' changes *visible* to
> Tx S!
Yes, but what's that got to do with the order of operations in
GetSnapshotData? The scenario you de
> > 1. Tx Old is running.
> > 2. Tx S reads new transaction ID in GetSnapshotData() and swapped away
> >before SInval acquired.
> > 3. Tx New gets new transaction ID, makes changes and commits.
> > 4. Tx Old changes some row R changed by Tx New and commits.
> > 5. Tx S gets snapshot data and n
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Since we are going to treat all xids >= xmax as in-progress anyway,
>> what's wrong with reading xmax before we acquire the SInval lock?
> AFAIR, I made so to prevent following:
> 1. Tx Old is running.
> 2. Tx S reads new transaction ID in GetSnaps
> I am trying to understand why GetSnapshotData() needs to acquire the
> SInval spinlock before it calls ReadNewTransactionId, rather than after.
> I see that you made it do so --- in the commit at
>
http://www.ca.postgresql.org/cgi/cvsweb.cgi/pgsql/src/backend/storage/ipc/sh
mem.c.diff?r1=1.41&r2
11 matches
Mail list logo
