On Sat, Mar 12, 2022 at 1:55 AM Robert Haas <robertmh...@gmail.com> wrote: > Responding to this specific issue..
> The changes to createdb_failure_params make me a little nervous. I > think we'd be in real trouble if we failed before completing both > DropDatabaseBuffers() and ForgetDatabaseSyncRequests(). However, it > looks to me like those are both intended to be no-fail operations, so > I don't see an actual hazard here. I might be missing something but even without that I do not see a real problem here. The reason we are dropping the database buffers and pending sync request is because right after this we are removing the underlying files and if we just remove the files without dropping the buffer from the buffer cache then the checkpointer will fail while trying to flush the buffer. But, hmm, what about on the > recovery side? Suppose that we start copying the database block by > block and then either (a) the standby is promoted before the copy is > finished or (b) the copy fails. I think the above logic will be valid in case of standby as well because we are not really deleting the underlying files. Now the standby has data in > shared_buffers for a database that does not exist. If that's not bad, > then why does createdb_failure_params need to DropDatabaseBuffers()? > But I bet it is bad. I wonder if we should be using > RelationCopyStorage() rather than this new function > RelationCopyStorageUsingBuffer(). I am not sure how RelationCopyStorage() will help in the standby side, because then also we will log the same WAL (XLOG_FPI) for each page and standby side we will use buffer to apply this FPI so if you think that there is a problem then it will be same with RelationCopyStorage() at least on the standby side. In fact while we are rewriting the relation during vacuum full that time also we are calling log_newpage() under RelationCopyStorage() and during standby if it gets promoted we will be having some buffers in the buffer pool with the new relfilenode. So I think our case is also the same. So here my stand is that we need to drop database buffers and remove pending sync requests because we are deleting underlying files and if we do not do that in some extreme cases then there is no need to drop the buffers or remove the pending sync request and the worst consequences would be waste of disk space. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com