locking ทำงานอย่างไรใน PostgreSQL?

Question

Accepted Answer

PostgreSQL ใช้ **lock** เพื่อประสานการเข้าถึงพร้อมกันและป้องกันความขัดแย้ง ด้วย **MVCC** การอ่านโดยทั่วไปไม่ต้องการ lock (ผู้อ่านไม่บล็อกผู้เขียน) แต่การเขียนจะ acquire row-level lock และ lock หลายชนิดประสานการดำเนินการ การเข้าใจ locking ช่วยหลีกเลี่ยง contention และ deadlock

## MVCC หมายความว่าการอ่านมักไม่ lock

```text
Because of MVCC, plain SELECTs do NOT take row locks — they read a consistent snapshot.
→ Readers don't block writers, writers don't block readers (a key Postgres advantage).
Locking mainly comes into play for WRITES and explicit locking.
```

## row-level lock (จากการเขียนและ explicit locking)

```sql
-- UPDATE/DELETE automatically lock the affected ROWS (until the transaction ends)
UPDATE accounts SET balance = balance - 100 WHERE id = 1;   -- locks row 1

-- SELECT ... FOR UPDATE — explicitly lock rows you intend to update (prevent races)
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;   -- lock the row
-- ... compute, then UPDATE — no other transaction can modify it meanwhile
UPDATE accounts SET balance = ... WHERE id = 1;
COMMIT;
```

`SELECT ... FOR UPDATE` lock แถวเพื่อให้ transaction ที่เกิดขึ้นพร้อมกันไม่สามารถแก้ไขมันได้ ป้องกัน race condition ในการดำเนินการ read-modify-write (เช่น การลดสินค้าคงคลังอย่างปลอดภัย)

## ชนิดของ lock และ table lock

```text
ROW-level → ACCESS via UPDATE/DELETE/SELECT FOR UPDATE — fine-grained
TABLE-level → some DDL (ALTER TABLE) takes heavier table locks → can block queries
→ Schema changes on busy tables can cause contention; plan migrations carefully
  (Postgres has gotten better — many ALTERs are now non-blocking, but not all).
```

## การหลีกเลี่ยงปัญหา lock และ deadlock

```text
✓ Keep transactions SHORT (hold locks briefly → less contention)
✓ Acquire locks in a CONSISTENT ORDER across transactions → avoid DEADLOCKS
✓ Use FOR UPDATE deliberately for read-modify-write; consider FOR UPDATE SKIP LOCKED
  for queue-like patterns (skip already-locked rows)
✓ Watch for long-held locks blocking others (pg_locks, pg_stat_activity to diagnose)
✓ Be cautious with DDL on busy tables (can block)
```

## ทำไมจึงสำคัญ

การเข้าใจ locking ของ PostgreSQL เป็นสิ่งสำคัญต่อการสร้างแอปพลิเคชันแบบ concurrent ที่ **ถูกต้องและมีประสิทธิภาพ** ดังนั้นจึงเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับระบบที่มีการเข้าถึงฐานข้อมูลพร้อมกันอย่างมีนัยสำคัญ

ข้อมูลเชิงลึกพื้นฐานคือ **MVCC หมายความว่าการอ่านมักไม่ lock** (ผู้อ่านไม่บล็อกผู้เขียน เป็นข้อได้เปรียบด้าน concurrency สำคัญของ Postgres) ดังนั้น locking จึงเกี่ยวข้องกับ **การเขียนและ explicit locking** เป็นหลัก

การเข้าใจ **row-level lock** (acquire โดย UPDATE/DELETE) และโดยเฉพาะ **`SELECT ... FOR UPDATE`** (การ lock แถวอย่างชัดเจนเพื่อป้องกัน race condition ในการดำเนินการ read-modify-write เช่น การลดสินค้าคงคลังอย่างปลอดภัยหรือการประมวลผลยอดคงเหลือ ที่หากไม่มี lock transaction ที่เกิดขึ้นพร้อมกันอาจทำให้ผลลัพธ์ไม่ถูกต้อง) เป็นสิ่งสำคัญต่อ **ความถูกต้อง** ในสถานการณ์ concurrent

การรู้ว่า **DDL/schema change สามารถ acquire table lock ที่หนักกว่า** (อาจบล็อก query บนตารางที่ยุ่ง เป็นข้อพิจารณาสำคัญเมื่อวางแผน migration แม้ว่า Postgres จะปรับปรุง ALTER หลายตัวให้ไม่บล็อกแล้ว) ช่วยหลีกเลี่ยง contention ระหว่างการ deploy

การเข้าใจวิธี **หลีกเลี่ยงปัญหา lock และ deadlock** การรักษา transaction ให้สั้น (ถือ lock สั้น ๆ), การ acquire lock ในลำดับที่สม่ำเสมอ (ป้องกัน deadlock), การใช้ `FOR UPDATE` อย่างจงใจ (และ `SKIP LOCKED` สำหรับรูปแบบ queue) และการวินิจฉัย lock contention (pg_locks, pg_stat_activity) เป็นสิ่งมีคุณค่าต่อประสิทธิภาพและความน่าเชื่อถือภายใต้ concurrency

เนื่องจาก concurrency มีอยู่โดยธรรมชาติในแอปพลิเคชันจริง และเนื่องจากการใช้ locking อย่างเหมาะสม (โดยเฉพาะ `FOR UPDATE` เพื่อความถูกต้องในการดำเนินการ read-modify-write และการหลีกเลี่ยง contention/deadlock) เป็นสิ่งที่ทำให้โค้ดฐานข้อมูลแบบ concurrent ถูกต้องและมีประสิทธิภาพ การเข้าใจ locking ของ PostgreSQL ทั้งโมเดล MVCC-no-read-locks, explicit row locking เพื่อความถูกต้อง, table lock จาก DDL และการหลีกเลี่ยง deadlock/contention จึงเป็นความรู้ระดับ senior ที่มีคุณค่าต่อการสร้างแอปพลิเคชันแบบ concurrent ที่แข็งแกร่งและการดำเนินการ Postgres ภายใต้ load เป็นความกังวลที่เกี่ยวข้องบ่อยซึ่งแสดงถึงความเข้าใจในการควบคุม concurrency ของฐานข้อมูล