RE: Re: Strangeness in xid allocation / snapshot setup
От | Mikheev, Vadim |
---|---|
Тема | RE: Re: Strangeness in xid allocation / snapshot setup |
Дата | |
Msg-id | 3705826352029646A3E91C53F7189E320166C5@sectorbase2.sectorbase.com обсуждение исходный текст |
Ответ на | Strangeness in xid allocation / snapshot setup (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Strangeness in xid allocation / snapshot setup
|
Список | 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
В списке pgsql-hackers по дате отправления: