Jason Tishler <jason@tishler.net> writes:
>> It would appear that if the process that deleted pg_internal.init is
>> still around, a rename to create a fresh pg_internal.init fails. I
>> cannot understand why this should be; surely it's either a Windows bug
>> or a cygwin bug?
> Actually, the root cause is due to the following Windows "feature":
> If one process has a file open (i.e, has a open handle), then other
> processes will not be able to perform certain operations on this file.
> Hence, until *all* handles open during the unlink() are closed, rename()
> (and other operations) will fail.
Hmm. But pg_internal.init is not held open, or shouldn't be. It should
be read once and immediately closed during backend startup. Are we
leaking an open file descriptor someplace?
Based on your description, there would be a small window for the problem
to occur anyway, but the window seems to be much larger than it oughta
be.
regards, tom lane
