> On Oct 4, 2026, at 12:11 AM, shihao zhong <[email protected]> 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
