Re: UNDO with FILEOPS, and the FLUX table AM

On Tue, Nov 10, 2026 at 3:56 AM shihao zhong <zhong950419(at)gmail(dot)com> wrote:

> Hi Greg,

Hi Shihao,

> Thanks for v9,
>
> I had a few thoughs here.

Most welcome as always.

> 1. If a checkpoint comes after a transaction writes its undo, a crash
> does not undo it. Replay starts at the redo point. CREATE
> DATABASE can hit this.

You're right. A loser whose UNDO batches all come before the redo point
is never seen by the startup undo phase, so nothing reverses it. I
reproduced it with a FileOpsCreate() in an open transaction, a
CHECKPOINT, and an immediate stop: the file survives the restart.
Without the CHECKPOINT it is removed.

> 2. A crash in the middle of CREATE DATABASE still seems to leave the
> new directory behind. With wal_log the undo only calls rmdir().
> That fails because the relation files are still inside. With file_copy
> the cleanup is only kept in memory, so the crash loses it.

Also right, for both strategies, with or without a checkpoint in
between:

WARNING: FILEOPS UNDO MKDIR: could not rmdir "base/16399": Directory not empty

> 3. These commands cannot run in a transaction block, so the
> subtransaction and 2PC code is never used. Could it wait for a user?

That is true of the in-tree callers today; only test_fileops reaches
those paths. I'd still like to keep them. The engine's subtransaction
and PREPARE handling is the part of 0001 that any later user that does
run inside a transaction block will depend on, and it is easier to
review it now, against FILEOPS and its tests, than to bring it back
later as a change to an engine that has already gone in. If others
would rather see 0001 without it, I'll take it out.

I found a few more oversights myself. An ordinary filesystem error in a
FileOps* call is a PANIC again, as in your v2 review. CREATE TABLESPACE
t LOCATION '/' takes the server down with "PANIC: could not chmod file
"/"". v9 runs the system call inside the critical section, after the
WAL flush.

All four were fixed in v8, in the commit that v9 left out: the system
call before the WAL record, the in-flight UNDO chains carried in the
checkpoint, FileOpsMkdirTree() for the new database directory, and the
abort record carrying the inverses (the gap I described in the v9 mail).

v10 will bring those fixes into 0001 and 0002.

best.

-greg