Re: UNDO with constant time recovery (CTR)

> On Oct 4, 2026, at 12:11 AM, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Gregm

Hello Shihao! Thanks for taking a look.

> Thank you for all the work on this. I like the approach of starting
> with FILEOPS and not with a new table AM. I tried 0001 to 0003 from
> v2 and have a few notes. Please correct me if I got something wrong.

You didn't, I did.

> 1. Most FILEOPS tests seem to need 0005 to run. 059 and 061 set
> logical_revert_naptime, which 0005 adds. 060 and 072 are skipped
> because test_fileops is only added to the build in 0005.

Yes, this was an oversight. I'm rebasing and reorganizing the
series now.

> 2. A crash in the middle of CREATE DATABASE still leaves the
> directory for me. With wal_log I get
>
> WARNING: FILEOPS UNDO MKDIR: could not rmdir "base/77777":
> Directory not empty
>
> With file_copy I do not see any undo run.

Good catch, and this should have been in my set of tests. I'll
add more and correct this.

> 3. A plain file system error can now crash the server. For example,
> when the tablespace directory is owned by root:
>
> CREATE TABLESPACE t LOCATION '/Users/Shared';
>
> On master I get
>
> ERROR: could not set permissions on directory "/Users/Shared":
> Operation not permitted
>
> With the patch I get
>
> PANIC: could not chmod file "/Users/Shared": Operation not
> permitted
>
> and all sessions are dropped while the server does crash recovery.
> I think it is because FileOpsChmod() calls chmod() inside the
> critical section, so the ERROR turns into a PANIC. The other FileOps
> functions look the same. Is that intended?

Nope, just a gross oversight on my part. Mostly corrected in my tree
this past week. I'd hoped to have something to attach today but I'm
not quite there yet.

> You asked about 0004 and 0005. I think it is fine to hold them for
> now.
>
> Thanks,
> Shihao

best.

-greg