Re: The curious case of two inserts, a shrinking xmax, and a ShareLock on transaction
От | Alvaro Herrera |
---|---|
Тема | Re: The curious case of two inserts, a shrinking xmax, and a ShareLock on transaction |
Дата | |
Msg-id | 20150923024438.GO295765@alvherre.pgsql обсуждение исходный текст |
Ответ на | The curious case of two inserts, a shrinking xmax, and a ShareLock on transaction (Jeff Dik <jeffdik@finecode.net>) |
Ответы |
Re: The curious case of two inserts, a shrinking xmax, and
a ShareLock on transaction
|
Список | pgsql-general |
Jeff Dik wrote: > I'd really love to learn: > > 1. Why the xmax for foo_id1 goes from 696 to 1 and what does that > mean? When two transactions want to lock the same row, the xmax field is a multixact, no longer a bare transaction ID. This is an object that resolves to multiple transaction IDs. > 2. How does transaction A know it needs to take a ShareLock on > transaction B? Because it reads the two transaction ID values from pg_multixact. > 3. What is a virtualtransaction and what do its numerator and denominator > mean? It's not a division operation (so no numerator/denominator). The part before the / is a backend ID and the part after the / is a local transaction counter. It's just an identifier for the transaction, useful for the time before the transaction acquires a transaction ID. This optimizes that a transaction that doesn't modify tuples does not need to acquire a transaction ID (and thus keeps transaction ID consumption rate low.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-general по дате отправления: