Re: UNDO with constant time recovery (CTR) - Mailing list pgsql-hackers

From shihao zhong
Subject Re: UNDO with constant time recovery (CTR)
Date
Msg-id CAGRkXqRo2T24U4DkwCS2Bc2+5-wqWFtcfx_D4QY7KTSuPFLGEA@mail.gmail.com
Whole thread
In response to Re: UNDO with constant time recovery (CTR)  (Greg Burd <greg@burd.me>)
Responses Re: UNDO with constant time recovery (CTR)
List pgsql-hackers
Hi Gregm

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.

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.

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.

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?

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

Thanks,
Shihao

pgsql-hackers by date:

Previous
From: Junwang Zhao
Date:
Subject: Re: Copy from JSON FORMAT.
Next
From: shihao zhong
Date:
Subject: Re: [Patch] New pg_stat_tablespace view