I wrote:
> It might be interesting to think about not requiring the ControlFileLock
> to be held while making new WAL segments. I think the only reason it
> does that is to ensure that link/rename failure can be treated as a hard
> error (because no one could have beat us to the filename), but we're
> already having to back off that stance for Windows ...
Just for the archives: I looked into doing this, and realized that the
reason we use a lock here is that on platforms without working link()
we use rename() to emplace new WAL segments. And rename() is defined
to unlink any existing file of the target name, which would be
completely unsafe to do.
On platforms with link() we could probably get away without a lock,
but I'm disinclined to introduce that much of a platform-specific
difference in behavior when we don't have to.
regards, tom lane
