Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-cygwin by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group