PostgreSQL 10.3读已提交隔离下分区表查询的竞争条件问题

咱们直接针对你的场景来拆解：在PostgreSQL 10.3的Read Committed隔离级别下，当你查询分区表foo时，另一个进程修改其中某个分区的数据，不会引入导致数据不一致或异常的竞争条件，原因如下：

1. Read Committed隔离级别的核心保障 #

Read Committed是PostgreSQL的默认隔离级别，它的核心特性是语句级快照：每个查询语句执行时，会创建一个当前已提交数据的快照，整个查询过程中都基于这个快照返回结果，不会看到查询开始后其他进程提交的修改，更不会看到未提交的脏数据。

2. 分区表查询的本质 #

当你执行SELECT * FROM foo WHERE id = 'something'时，PostgreSQL会自动解析WHERE条件，定位到匹配的分区（比如如果这个id对应的state是pending，就只会扫描foo_pending分区），这个扫描过程和查询普通表没有本质区别，同样受MVCC（多版本并发控制）机制保护。

3. 并发DML操作的交互逻辑 #

如果另一个进程正在对目标分区执行INSERT/UPDATE/DELETE这类DML操作：

• 如果修改还未提交：查询的语句快照看不到这些未提交的变更，只会返回快照生成时已提交的数据，不会出现脏读。
• 如果修改在查询过程中提交：由于查询是基于语句开始时的快照，也不会读到这个新提交的数据，保证了整个查询结果的一致性。
• 当查询扫描到正在被修改的行时，MVCC会自动提供该行的已提交旧版本给查询，不会阻塞查询进程，也不会导致查询返回错误或混乱的数据。

例外情况：DDL操作的影响 #

如果另一个进程执行的是修改分区结构的DDL操作（比如ALTER TABLE foo_pending ADD COLUMN、DROP PARTITION等），这类操作会持有排他锁，可能导致查询暂时等待锁释放，但这属于锁等待范畴，不是数据层面的竞争条件，等待锁释放后查询仍会正常执行并返回一致结果。

总结来说，在你描述的场景下，正常的DML并发修改不会给分区表查询带来竞争条件，PostgreSQL的MVCC和Read Committed的快照机制已经帮你处理了并发一致性问题。

内容的提问来源于stack exchange，提问作者Davide R.