MVCC internals — xmin, xmax, snapshot, và vì sao SELECT không block UPDATE

Bạn mở hai psql session. Session A chạy UPDATE tasks SET title = 'X' WHERE id = 1 và chưa COMMIT. Session B chạy SELECT title FROM tasks WHERE id = 1 ngay lúc đó — và trả kết quả tức thì, không chờ, không block. Đồng thời cả hai đều nhìn thấy trạng thái nhất quán của row đó. Nghe như magic — làm sao một SELECT có thể đọc row đang bị UPDATE mà không nhìn thấy dữ liệu nửa chừng?

Câu trả lời là MVCC — Multi-Version Concurrency Control. Không có lock nào bảo vệ reader khỏi writer. Thay vào đó, PostgreSQL lưu nhiều phiên bản của cùng một row trên heap page, mỗi phiên bản có metadata về transaction nào tạo ra và transaction nào xoá nó đi. Reader chọn phiên bản đúng với "thời điểm logic" của mình — gọi là snapshot — mà hoàn toàn không cần block writer.

Bài này mở từng lớp của cơ chế đó: hidden columns, cách UPDATE thực sự hoạt động, snapshot visibility rule, hint bits để tối ưu hoá, CLOG để lưu commit status, và so sánh với cách MySQL InnoDB làm khác đi.

1. Analogy — Thư viện lưu mọi phiên bản sách

Hãy hình dung một thư viện không bao giờ xoá sách cũ — thay vào đó, mỗi lần sách được sửa đổi, thư viện tạo một bản in mới và giữ nguyên bản cũ trên kệ.

2. Vấn đề concurrency cũ — lock-based isolation

Trước MVCC, database dùng lock-based isolation: SELECT đặt shared lock, UPDATE đặt exclusive lock. Reader block writer, writer block reader. Throughput đổ vỡ ngay khi có nhiều user đồng thời.

Oracle và SQL Server truyền thống (trước khi thêm MVCC) dùng kiểu này: SELECT lấy shared lock trên row đọc, UPDATE phải chờ hết shared lock mới lấy được exclusive lock. Kết quả: read workload và write workload block lẫn nhau.

PostgreSQL từ version đầu đã chọn hướng khác: reader không bao giờ block writer, writer không bao giờ block reader. Cơ chế cho phép điều đó là MVCC — lưu nhiều phiên bản tuple, mỗi transaction chọn phiên bản phù hợp theo snapshot của mình.

Trade-off: không có lock-based blocking → throughput cao → nhưng phải quản lý dead tuple, cần VACUUM. Đây là trade-off cốt lõi của thiết kế PostgreSQL.

3. xmin, xmax, ctid — hidden columns trên mỗi tuple

PostgreSQL lưu metadata MVCC trực tiếp trong header của mỗi tuple trên heap page. Bốn cột ẩn quan trọng nhất:

Truy vấn trực tiếp các hidden column này — PostgreSQL cho phép gọi tên chúng trong SELECT:

-- Truy van hidden columns truc tiep
SELECT xmin, xmax, ctid, id, title, status
FROM tasks
WHERE id IN (1, 2);

-- xmin | xmax | ctid  | id | title      | status
--  100 |    0 | (0,1) |  1 | Deploy API | todo
--  100 |    0 | (0,2) |  2 | Write docs | todo
-- xmax = 0 nghia la chua bi delete hoac update

Bây giờ chạy UPDATE và xem điều gì xảy ra:

-- Trong session A (txid = 101):
BEGIN;
UPDATE tasks SET title = 'Deploy API v2' WHERE id = 1;
-- CHUA COMMIT

-- Trong session B, doc hidden column:
SELECT xmin, xmax, ctid, id, title
FROM tasks
WHERE id = 1;

-- Session B thay tuple cu (xmax = 101 nhung 101 chua commit):
-- xmin | xmax | ctid  | id | title
--  100 |  101 | (0,1) |  1 | Deploy API

-- Session A commit:
-- COMMIT; (trong session A)

-- Gio session B doc lai:
SELECT xmin, xmax, ctid, id, title FROM tasks WHERE id = 1;
-- xmin | xmax | ctid  | id | title
--  101 |    0 | (0,3) |  1 | Deploy API v2
-- Tuple moi: xmin=101, xmax=0, ctid khac (page 0, offset 3)
-- Tuple cu xmin=100 xmax=101 van con tren heap -- "dead tuple", doi VACUUM reclaim

Hai điểm quan trọng: (1) UPDATE tạo tuple mới với xmin = txid hiện tại, không sửa tuple cũ tại chỗ. (2) Tuple cũ có xmax được đặt = txid của UPDATE — nó vẫn tồn tại trên heap và sẽ invisible với các snapshot sau khi xmax committed.

4. UPDATE = INSERT tuple mới + set xmax tuple cũ

Đây là điểm trái ngược hoàn toàn với cách ta thường nghĩ về UPDATE. Trong PostgreSQL, UPDATE tasks SET title = 'X' WHERE id = 1 thực sự làm hai việc nguyên tử:

1. Set xmax trên tuple cũ = txid của transaction đang UPDATE.
2. INSERT một tuple mới với xmin = txid hiện tại, xmax = 0, chứa giá trị mới.

Tuple cũ không bị xoá ngay. Nó vẫn nằm trên heap page, chờ VACUUM reclaim sau khi không còn snapshot nào cần nhìn thấy nó. Kết quả: tại bất kỳ thời điểm nào trong khi UPDATE đang chạy (chưa commit), cả hai phiên bản đều tồn tại trên heap.

Heap page truoc UPDATE:
+------------------+------------------+
| Tuple v1         |                  |
| xmin=100 xmax=0  |   (free space)   |
| ctid=(0,1) id=1  |                  |
| title="Deploy"   |                  |
+------------------+------------------+

Sau UPDATE (txid=101, chua commit):
+------------------+------------------+
| Tuple v1         | Tuple v2         |
| xmin=100 xmax=101|  xmin=101 xmax=0 |
| ctid=(0,1) id=1  |  ctid=(0,2) id=1 |
| title="Deploy"   |  title="Deploy v2"|
+------------------+------------------+

Snapshot truoc txid 101 commit: chi thay v1
Snapshot sau txid 101 commit: chi thay v2 (v1 la dead tuple)

HOT update (Heap-Only Tuple): nếu indexed column không thay đổi và cùng heap page còn chỗ, PG có thể làm HOT update — tuple mới nằm cùng page với tuple cũ, không cần update B-tree index. Index vẫn trỏ tới tuple cũ; tuple cũ có ctid trỏ sang tuple mới (chain pointer). Đây là tối ưu quan trọng cho throughput UPDATE trên bảng có nhiều index.

5. Snapshot — xmin, xip_list, xmax

Khi transaction bắt đầu (hoặc khi statement đầu tiên chạy ở READ COMMITTED), PostgreSQL chụp một snapshot mô tả "trạng thái thế giới lúc này":

Snapshot = (snap_xmin, snap_xmax, xip_list)

- snap_xmin: txid nhỏ nhất đang còn active lúc snapshot taken.
             Mọi tuple xmin < snap_xmin: đã committed "lâu rồi", safe to see.
- snap_xmax: txid tiếp theo sẽ được assign (chưa tồn tại).
             Mọi tuple xmin >= snap_xmax: không tồn tại theo snapshot này.
- xip_list:  danh sách các txid đang active lúc snapshot taken.
             Tuple có xmin trong xip_list: đang in-progress, chưa commit.

Visibility rule (đầy đủ cho tuple thường):

Một tuple (xmin, xmax) visible theo snapshot S khi và chỉ khi:

1. xmin đã committed AND (xmin < S.snap_xmin OR xmin không có trong S.xip_list)
2. AND (xmax = 0 OR xmax chưa committed OR xmax >= S.snap_xmax OR xmax có trong S.xip_list)

Điều kiện 1: đảm bảo tuple đã được tạo bởi một committed transaction trước hoặc ngoài snapshot (tức là nằm trong "quá khứ" của snapshot). Điều kiện 2: đảm bảo tuple chưa bị xoá/update bởi committed transaction trong "quá khứ" của snapshot.

Ví dụ cụ thể: txid 100 committed, txid 101 đang active trong xip_list. Tuple (xmin=101, xmax=0) → xmin=101 có trong xip_list → điều kiện 1 fail → tuple invisible. Đúng: đây là row đang UPDATE chưa commit, không được thấy.

6. Timeline T1/T2 — snapshot stable per Repeatable Read

Scenario: hai session đồng thời, T1 update, T2 đọc hai lần:

sequenceDiagram
    participant T1 as Session T1 (txid 100)
    participant T2 as Session T2 (txid 101)
    participant H as Heap page

    T1->>H: BEGIN — snapshot {snap_xmin=99, xip=[100]}
    T2->>H: BEGIN (RR) — snapshot {snap_xmin=99, xip=[100,101]}
    T1->>H: UPDATE tasks SET title='X' WHERE id=1
    Note over H: Tuple v1: xmin=80 xmax=100<br/>Tuple v2: xmin=100 xmax=0
    T2->>H: SELECT title FROM tasks WHERE id=1
    Note over T2: xip=[100,101] → v2 xmin=100 in xip → invisible<br/>v1 xmin=80 < snap_xmin=99 → committed, visible<br/>Ket qua: title cu
    T1->>H: COMMIT (100 marked committed in CLOG)
    T2->>H: SELECT title FROM tasks WHERE id=1 (RR — same snapshot)
    Note over T2: Snapshot khong doi — xip van la [100,101]<br/>100 van trong xip → v2 van invisible<br/>Van thay title cu (Repeatable Read dam bao nay)
    T2->>H: COMMIT

Điểm mấu chốt: ở REPEATABLE READ, snapshot được chụp một lần khi BEGIN và giữ nguyên xuyên suốt transaction. Kể cả sau khi T1 commit, T2 vẫn thấy data cũ vì snapshot của T2 vẫn coi txid 100 là "đang active". Đây chính là Repeatable Read guarantee — đọc cùng row hai lần trong một transaction, thấy cùng kết quả.

Ở READ COMMITTED (default PostgreSQL), snapshot được chụp lại cho mỗi statement. Lần SELECT thứ hai của T2 (sau T1 commit) sẽ chụp snapshot mới không còn txid 100 trong xip_list → v2 visible → thấy title mới. Đây là non-repeatable read — hợp lệ ở READ COMMITTED nhưng không hợp lệ ở REPEATABLE READ.

7. PostgreSQL vs MySQL InnoDB — hai triết lý MVCC

Cùng mục tiêu (reader không block writer), nhưng implement theo hai hướng khác nhau hoàn toàn:

PG: ưu điểm — write throughput cao hơn (INSERT mới nhanh, không cần traverse undo), không có contention trên shared undo tablespace. Nhược điểm — cần VACUUM chủ động để reclaim dead tuple; nếu autovacuum không đuổi kịp write load, heap bloat tích lũy.

InnoDB: ưu điểm — purge tự động hơn, không cần DBA quan tâm VACUUM. Nhược điểm — undo log có thể bloat rất lớn khi có long-running transaction (undo chain không thể purge khi có snapshot còn active).

8. Hint bits — tối ưu hoá visibility check

Mỗi lần kiểm tra visibility một tuple, PostgreSQL cần biết: xmin đã committed chưa? xmax đã committed chưa? Câu trả lời nằm trong CLOG (pg_xact) — phải đọc file trên disk nếu không có trong bộ nhớ. Nếu mỗi tuple read đều phải tra CLOG, chi phí tích lũy rất lớn.

Hint bits là giải pháp: mỗi tuple có 4 flag bit trong header:

Workflow:

1. Lần đầu visibility check một tuple mới: HEAP_XMIN_COMMITTED chưa set → phải tra CLOG → kiểm tra commit status của xmin.
2. Nếu xmin đã committed → set HEAP_XMIN_COMMITTED ngay trên tuple header (best-effort, không WAL-logged).
3. Lần sau tra cùng tuple: HEAP_XMIN_COMMITTED đã set → skip CLOG lookup hoàn toàn.

Hệ quả thực tế bạn có thể quan sát:

-- Insert 1 trieu row, do thoi gian SELECT dau tien vs thu hai
-- (hint bits chua set sau INSERT)
INSERT INTO tasks (project_id, title, status)
SELECT 1, 'Task ' || g, 'todo'
FROM generate_series(1, 1000000) g;

-- SELECT 1: phai set hint bits cho ~1M tuple -> cham hon
\timing on
SELECT count(*) FROM tasks;
-- Time: 320 ms (vi du)

-- SELECT 2: hint bits da set, skip CLOG lookup
SELECT count(*) FROM tasks;
-- Time: 95 ms (nhanh hon dang ke)

Hint bits cũng giải thích tại sao lần SELECT * đầu tiên sau VACUUM hoặc sau bulk INSERT thường chậm hơn lần tiếp theo — đó là chi phí set hint bits cho các tuple mới chưa được kiểm tra.

9. CLOG (pg_xact) — commit status của mỗi transaction

CLOG (Commit Log) lưu trạng thái của mọi transaction ID đã từng tồn tại. Vị trí: $PGDATA/pg_xact/ (đổi tên từ pg_clog ở PG 10).

Cấu trúc: 2 bit per txid, encode 4 trạng thái:

Kích thước file: mỗi segment 256 KB chứa trạng thái của 256 KB × 8 bit/byte / 2 bit/txid = 1,048,576 txid. Ở workload cao (10,000 tx/giây), một segment đủ cho khoảng 100 giây — PG tự động tạo segment mới khi cần.

# Xem cac segment CLOG hien co
ls -lh $PGDATA/pg_xact/
# -rw------- 1 postgres postgres 256K  ...  0000
# -rw------- 1 postgres postgres 256K  ...  0001
# ...
# Moi segment 256KB = 1M txid

CLOG được giữ trong bộ nhớ (shared buffer dành riêng cho CLOG) và flush định kỳ. Hint bits sinh ra để giảm CLOG lookup — một khi hint bit đã set, tuple không bao giờ tra CLOG nữa.

10. Pitfall — txid wraparound và long transaction

-- Kiem tra "tuoi" txid cua database (phai < 2,000,000,000)
SELECT datname, age(datfrozenxid) AS xid_age
FROM pg_database
ORDER BY xid_age DESC;

-- xid_age | datname
-- 1800000000 | taskflow  <-- NGUY HIEM: autovacuum freeze can chay gap
-- autovacuum_freeze_max_age mac dinh: 200,000,000 (nen da trigger truoc do)

-- Phat hien transaction giu snapshot lau (co the block VACUUM)
SELECT
  pid,
  now() - pg_stat_activity.query_start AS duration,
  age(backend_xmin) AS xmin_age,
  state,
  left(query, 80) AS query_preview
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL
ORDER BY xmin_age DESC
LIMIT 10;

-- xmin_age cao (hàng tram ngan) = snapshot cu
-- VACUUM khong the reclaim dead tuple co xmax < xmin cua snapshot nay
-- -> heap bloat tich luy theo thoi gian

-- Neu can, terminate tx giu snapshot:
-- SELECT pg_terminate_backend(pid) WHERE pid = <pid_cu>;

11. Applied — TaskFlow dashboard consistent view

Scenario thực tế: dashboard TaskFlow hiển thị hai số liệu — tổng task và số task đã hoàn thành — để tính phần trăm tiến độ. Nếu hai query chạy độc lập ở READ COMMITTED, có thể xảy ra "data flash" không nhất quán:

-- ANTI-PATTERN: 2 query rieng o READ COMMITTED
-- Giua query 1 va query 2, user khac commit 1 task moi trang thai 'done'
SELECT count(*) FROM tasks WHERE project_id = 42;          -- tra ve 100
-- (user X commit: INSERT task moi + UPDATE 1 task sang 'done')
SELECT count(*) FROM tasks WHERE project_id = 42
  AND status = 'done';                                     -- tra ve 51
-- Ket qua: 51/100 = 51% -- nhung thuc te chi co 50 task 'done' truoc snapshot dau
-- Va 100 la so moi (chua co khi chup snapshot query 1)
-- -> ti le sai

Fix: bọc hai query trong một REPEATABLE READ transaction — cả hai dùng cùng một snapshot, nhìn thấy cùng thời điểm logic:

-- DUNG: RR transaction dam bao consistent snapshot xuyen suot
BEGIN ISOLATION LEVEL REPEATABLE READ;

SELECT count(*) AS total_tasks
FROM tasks
WHERE project_id = 42;
-- Snapshot chup tai day (hoac tai BEGIN, tuy implementation)

SELECT count(*) AS done_tasks
FROM tasks
WHERE project_id = 42
  AND status = 'done';
-- Cung snapshot -> 2 so lieu thuoc cung thoi diem logic

COMMIT;
-- Ket qua: ti le chinh xac, khong bi "data flash" giua 2 query

Đây là ứng dụng trực tiếp của MVCC: cùng một heap page được đọc hai lần với cùng snapshot → cả hai lần đều thấy đúng phiên bản tuple phù hợp với snapshot đó → kết quả nhất quán. Không có lock nào trên bảng tasks trong suốt quá trình — writer vẫn tự do INSERT/UPDATE song song.

12. Deep Dive

13. Tóm tắt

• MVCC = nhiều phiên bản tuple: PostgreSQL lưu nhiều version của cùng một row trên heap page, mỗi version có xmin (ai tạo) và xmax (ai xoá/update). Reader và writer không bao giờ block nhau.
• UPDATE = INSERT mới + set xmax cũ: không sửa tuple tại chỗ. Tuple cũ có xmax = txid của UPDATE và tồn tại trên heap cho đến khi VACUUM reclaim.
• Snapshot = (snap_xmin, snap_xmax, xip_list): chụp tại BEGIN (RR/Serializable) hoặc tại mỗi statement (RC). Xác định tuple nào visible với transaction đó.
• Visibility rule: xmin phải committed và nằm ngoài xip_list; xmax phải 0 hoặc chưa committed hoặc nằm trong xip_list.
• RR giữ snapshot stable: đọc cùng row hai lần trong transaction → cùng kết quả. RC chụp snapshot mới mỗi statement → có thể thấy kết quả khác nhau.
• Hint bits tránh CLOG lookup lặp lại: sau lần check đầu, HEAP_XMIN_COMMITTED được set → lần sau skip CLOG hoàn toàn → SELECT thứ 2 nhanh hơn đáng kể.
• CLOG (pg_xact): 2 bit/txid, 4 trạng thái (in-progress/committed/aborted/sub-committed). Mỗi segment 256 KB chứa 1M txid.
• Long transaction block VACUUM: snapshot xmin thấp → VACUUM không reclaim dead tuple có xmax lớn hơn → heap bloat tích lũy. Monitor bằng age(backend_xmin) trong pg_stat_activity.
• txid wraparound (32-bit): autovacuum freeze phải chạy trước khi age(datfrozenxid) vượt 2 tỷ. Giám sát bằng age(datfrozenxid) trong pg_database.

14. Tự kiểm tra

Bài tiếp theo: VACUUM & dead tuples — vì sao TaskFlow phình to dù count(*) không tăng