On Mon, Mar 21, 2022 at 3:02 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > 2. Why not instead change the code so that the operation can succeed, > > by creating the prerequisite parent directories? Do we not have enough > > information for that? I'm not saying that we definitely should do it > > that way rather than this way, but I think we do take that approach in > > some cases. > > It seems we can choose freely between these two implementations -- I > mean I don't see any upsides or downsides to either one.
What got committed here feels inconsistent to me. Suppose we have a checkpoint, and then a series of operations that touch a tablespace, and then a drop database and drop tablespace. If the first operation happens to be CREATE DATABASE, then this patch is going to fix it by skipping the operation. However, if the first operation happens to be almost anything else, the way it's going to reference the dropped tablespace is via a block reference in a WAL record of a wide variety of types. That's going to result in a call to XLogReadBufferForRedoExtended() which will call XLogReadBufferExtended() which will do smgrcreate(smgr, forknum, true) which will in turn call TablespaceCreateDbspace() to fill in all the missing directories. I don't think that's very good. It would be reasonable to decide that we're never going to create the missing directories and instead just remember that they were not found so we can do a cross check. It's also reasonable to just create the directories on the fly. But doing a mix of those systems doesn't really seem like the right idea - particularly because it means that the cross-check system is probably not very effective at finding actual problems in the code. Am I missing something here? -- Robert Haas EDB: http://www.enterprisedb.com