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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Prefixing libpq error message with function names
Следующее
От: "Mikheev, Vadim"
Дата:
Сообщение: RE: Rule recompilation