Hello. At Tue, 23 Apr 2019 13:31:58 +0800, Paul Guo <p...@pivotal.io> wrote in <caeet0zecwz57z2yfwrds43b3tfqppdswmbjgmd43xrxlt41...@mail.gmail.com> > Hi Kyotaro, ignoring the MakePGDirectory() failure will fix this database > create redo error, but I suspect some other kind of redo, which depends on > the files under the directory (they are not copied since the directory is > not created) and also cannot be covered by the invalid page mechanism, > could fail. Thanks.
If recovery starts from just after tablespace creation, that's simple. The Symlink to the removed tablespace is already removed in the case. Hence server innocently create files directly under pg_tblspc, not in the tablespace. Finally all files that were supposed to be created in the removed tablespace are removed later in recovery. If recovery starts from recalling page in a file that have been in the tablespace, XLogReadBufferExtended creates one (perhaps directly in pg_tblspc as described above) and the files are removed later in recoery the same way to above. This case doen't cause FATAL/PANIC during recovery even in master. XLogReadBufferExtended@xlogutils.c | * Create the target file if it doesn't already exist. This lets us cope | * if the replay sequence contains writes to a relation that is later | * deleted. (The original coding of this routine would instead suppress | * the writes, but that seems like it risks losing valuable data if the | * filesystem loses an inode during a crash. Better to write the data | * until we are actually told to delete the file.) So buffered access cannot be a problem for the reason above. The remaining possible issue is non-buffered access to files in removed tablespaces. This is what I mentioned upthread: me> but I haven't checked this covers all places where need the same me> treatment. -- Kyotaro Horiguchi NTT Open Source Software Center
