Re: reproduced elusive cygwin bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jason Tishler <jason(at)tishler(dot)net>
Cc: Michael Adler <adler(at)glimpser(dot)org>, Pgsql-Cygwin <pgsql-cygwin(at)postgresql(dot)org>
Subject: Re: reproduced elusive cygwin bug
Date: 2002-01-16 15:40:52
Message-ID: 9289.1011195652@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-cygwin

Jason Tishler <jason(at)tishler(dot)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

In response to

Responses

Browse pgsql-cygwin by date

  From Date Subject
Next Message Tom Pfau 2002-01-16 16:00:27 Re: reproduced elusive cygwin bug
Previous Message Tom Pfau 2002-01-16 15:30:29 Re: reproduced elusive cygwin bug