Thread

[PATCH] Avoid orphaning buffers when a relation's file is missing

Adam Lee <adam8157@gmail.com> — 2026-06-09T09:55:04Z

Hi,

Hit a case where the server can't checkpoint anymore, and it comes down to the
targeted-drop optimization in DropRelationsAllBuffers().

The scenario is disaster recovery: a relation's data file has gone missing
on disk (failed restore, lost/again-detached storage, a half-finished manual
cleanup, ...), and the administrator does the natural thing -- DROP the
broken relation to get the system going again. The catch is that a dirty
buffer for that relation can still be resident in shared buffers, and every
checkpoint after that fails trying to write it back:

    could not open file "..." while writing block N of relation ...

Before bea449c635c the full scan always ran, so dropping the relation cleaned
the buffer up regardless of the file. The attached patch restores that for the
main fork only -- fsm/vm/init are routinely absent (a permanent rel never has
an init fork), so forcing a full scan on their absence would kill the
optimization for almost every drop.

No in-core reproducer since it needs the file to vanish underneath us, but the
path is clear once it does. Patch attached.

-- 
Adam