From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Jeff Dik <jeffdik(at)finecode(dot)net> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: The curious case of two inserts, a shrinking xmax, and a ShareLock on transaction |
Date: | 2015-09-23 02:44:38 |
Message-ID: | 20150923024438.GO295765@alvherre.pgsql |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Begin | 2015-09-23 11:37:22 | Re: Advise on memory usage limitation by PostgreSQL on Windows |
Previous Message | Jeff Dik | 2015-09-23 02:31:04 | The curious case of two inserts, a shrinking xmax, and a ShareLock on transaction |