Re: Hash index corruption and CLOG lookup errors from checkpoint races

On Sun, 1 Nov 2026 at 06:35, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> 2. _hash_alloc_buckets() WAL-logs the new splitpoint before it extends
> the file. If a base backup starts in between, the hash index on the new
> standby or restored server is broken. It looks fine at first. Once the
> index needs an overflow page, inserts fail with "access to noncontiguous
> page" until a REINDEX.
>
> A power loss at the same moment can do the same on the primary.
>
> 0003 sets DELAY_CHKPT_START around the two steps,
> like bulk_write.c. 0004 is the repro.

Thanks for identifying this issue.
I noticed one issue:
After DELAY_CHKPT_START is set, itcan fail with an ordinary ERROR, for
example, due to lack of disk space. If this happens, the flag is left
set. A top-level abort clears it through ProcArrayEndTransaction(),
but AbortSubTransaction() does not. So if the error is caught by a
savepoint or a PL/pgSQL EXCEPTION block, the flag remains set for the
rest of the transaction. Every checkpoint then waits in
CheckpointDelayStart until that transaction ends. Even an
idle-in-transaction session can block checkpoints. The attached test
uses the error action of the new hash-alloc-buckets-after-wal
injection point to reproduce this issue.

Regards,
Vignesh