On Fri, Jan 19, 2018 at 5:19 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> Regarding the HOT issue - I have to admit I don't quite see why A2
> wouldn't be reachable through the index, but that's likely due to my
> limited knowledge of the HOT internals.
The index entries only point to the root tuple in the HOT chain. Any
subsequent entries can only be reached by following the CTID pointers
(that's why they are called "Heap Only Tuples"). After T1 aborts,
we're still OK because the CTID link isn't immediately cleared. But
after T2 updates the tuple, it makes A1's CTID link point to A3,
leaving no remaining link to A2.
Although in most respects PostgreSQL treats commits and aborts
surprisingly symmetrically, CTID links are an exception. When T2
comes to A1, it sees that A1's xmax is T1 and checks the status of T1.
If T1 is still in progress, it waits. If T2 has committed, it must
either abort with a serialization error or update A2 instead under
EvalPlanQual semantics, depending on the isolation level. If T2 has
aborted, it assumes that the CTID field of T1 is garbage nobody cares
about, adds A3 to the page, and makes A1 point to A3 instead of A2.
No record of the A1->A2 link is kept anywhere *precisely because* A2
can no longer be visible to anyone.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
