On 2019-May-13, Robert Haas wrote: > I think I see what Alvaro is talking about, or at least I think I see > *a* possible problem based on his remarks. > > Suppose we create an unlogged table and then crash. The main fork > makes it to disk, and the init fork does not. Before WAL replay, we > remove any main forks that have init forks, but because the init fork > was lost, that does not happen. Recovery recreates the init fork. > After WAL replay, we try to copy_file() each _init fork to the > corresponding main fork. That fails, because copy_file() expects to be > able to create the target file, and here it can't do that because it > already exists.
... right, that seems to be it. > If that's the scenario, I'm not sure the smgrimmedsync() call is > sufficient. Suppose we log_smgrcreate() but then crash before > smgrimmedsync()... seems like we'd need to do them in the other order, > or else maybe just pass a flag to copy_file() telling it not to be so > picky. Well, if we do modify copy_file and thus we don't think the deletion step serves any purpose, why not just get rid of the deletion step entirely? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
