Hi, On 2022-03-02 14:52:01 -0500, Robert Haas wrote: > - I am having some trouble understanding clearly what 0001 is doing. > I'll try to study it further.
It tests for the various scenarios I could think of that could lead to FD reuse, to state the obvious ;). Anything particularly unclear. > - In general, 0003 makes a lot of sense to me. > > + /* > + * Finally tell the kernel to write the data to > storage. Don't smgr if > + * previously closed, otherwise we could end up evading > fd-reuse > + * protection. > + */ > > - I think the above hunk is missing a word, because it uses smgr as a > verb. I also think that it's easy to imagine this explanation being > insufficient for some future hacker to understand the issue. Yea, it's definitely not sufficient or gramattically correct. I think I wanted to send something out, but was very tired by that point.. > - While 0004 seems useful for testing, it's an awfully big hammer. I'm > not sure we should be thinking about committing something like that, > or at least not as a default part of the build. But ... maybe? Aggreed. I think it's racy anyway, because further files could get deleted (e.g. segments > 0) after the barrier has been processed. What I am stuck on is what we can do for the released branches. Data corruption after two consecutive ALTER DATABASE SET TABLESPACEs seems like something we need to address. Greetings, Andres Freund
