Concurrent DELETEs to the same chunk group can drop delete marks

[jdatcmd]

Summary

Concurrent DELETEs that touch the same chunk group can lose one transaction's delete marks.

Detail

Deletes are recorded by setting bits in a single shared columnar.row_mask heap tuple per (storage id, stripe, chunk group). When two transactions concurrently delete different rows in the same chunk group, they contend on that one tuple. Under READ COMMITTED a last-writer-wins update to the mask can drop the delete bits set by the other transaction, so a row that was deleted can remain visible.

Single-session correctness is not affected. This only occurs with concurrent writers to the same chunk group.

Source

src/columnar_row_mask.c.

Why it is not a quick fix

A correct fix needs row-level locking on the mask or a merge of concurrent mask updates rather than a full-tuple overwrite. That is a design change, not a targeted patch, which is why it is tracked separately rather than bundled into the delete implementation.

Status

Documented in the README limitations section. Tracked here for a future dedicated pass.

[jdatcmd]

Fixed in 1de539b (fix) and 8ce9fee (concurrency test hardening), on main.

Root cause: the row_mask read-modify-write on delete was unguarded, so two transactions deleting different rows in the same chunk group could both read the old mask and overwrite each other, losing one transaction's delete marks. The first delete of a chunk group could also race on the row_mask unique index.

Fix: serialize the read-modify-write of a given (storage id, stripe, chunk group) mask with a transaction-scoped advisory lock (keyed by a hash of the three ids, database-scoped), then re-read the committed mask and merge (bitwise OR) the new bits. This covers both the update path and the first-delete insert race with one primitive, needs no subtransaction (safe in the pre-commit flush), and keeps the on-disk format 2.0 unchanged. Chunk buffers are sorted by (stripe, chunk, start row) before flush to give a consistent lock order and avoid AB-BA deadlocks.

Behavior change: concurrent deletes or updates to the SAME chunk group now serialize briefly (until commit) and both sets of marks survive. Deletes to different chunk groups still proceed concurrently. Documented in README.

Tests: test/concurrency.sh drives two psql sessions with a pg_stat_activity lock-wait barrier and asserts both deletes survive across three scenarios (existing mask, first-delete insert race, and different-group non-blocking). It fails on the pre-fix tree and passes after. The full PostgreSQL 13 to 19 by seven-suite matrix (including concurrency) passes via test/run_all_versions.sh.

Residual: concurrent same-chunk-group writers serialize for the brief lock window (intended, documented). The unrelated concurrent-insert unique-miss window is tracked in #5.