I am in the middle of studying PostgreSQL MVCC approach when I stumbled upon the two hint bits which marked xmin/xmax to be "in progress", "committed", or "aborted". I just want to make sure that I got my understanding right with regards to Postgres' XLOG and Buffer management.
1. When a transaction T updates a tuple X, it creates a new version of the tuple, and then leave the hint bits unset (xmin/xmax in progress). Let's say the tuple is located in page P.
2. Buffer manager may evict page P from cache even before transaction T commits/aborts. However, it must do so only after HEAP_UPDATE is written to XLOG.
3. When transaction T eventually commits/aborts, we only have to set appropriate CLOG bits for T, but we never have to touch the hint bits of the tuples modified by transaction T.
4. Only when another transaction inspects tuple X, it realizes that the hint bits are unset and needs to inspect CLOG to see the outcome of xmin/xmax. If there is any change in outcome, the hint bits of tuple X will be set.
5. So it is actually possible for tuples created by aborted transaction to appear on disk. However this should pose no problem as they will never be visible to any transaction, and Vacuum process will eventually get rid of them.
I am really unsure about point 2, because I couldn't find any definite statement whether a dirty page could be written before transaction commits. All it makes clear is that the XLOG record describing the change must be present on disk before the dirty page, but that does not seem to prohibit dirty pages to be written before commit time. The consequence is as described in point 5, the transaction which created the tuple might turn out to be aborted, and those tuples will be invalid and efforts will be wasted.
Thanks in advance for your help and clarification.
Prima