Re: reproduced elusive cygwin bug
От | Tom Lane |
---|---|
Тема | Re: reproduced elusive cygwin bug |
Дата | |
Msg-id | 9289.1011195652@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: reproduced elusive cygwin bug (Jason Tishler <jason@tishler.net>) |
Ответы |
Re: reproduced elusive cygwin bug
Re: reproduced elusive cygwin bug |
Список | pgsql-cygwin |
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
В списке pgsql-cygwin по дате отправления: