From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | RE: Re: Strangeness in xid allocation / snapshot setup |
Date: | 2001-07-12 17:36:30 |
Message-ID: | 3705826352029646A3E91C53F7189E320166C5@sectorbase2.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2001-07-12 17:41:00 | RE: Rule recompilation |
Previous Message | Jan Wieck | 2001-07-12 17:28:59 | Rule recompilation |