Re: Re: Cygwin PostgreSQL Regression Test Problems
От | Bruce Momjian |
---|---|
Тема | Re: Re: Cygwin PostgreSQL Regression Test Problems |
Дата | |
Msg-id | 200101181858.NAA07791@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Cygwin PostgreSQL Regression Test Problems (Jason Tishler <Jason.Tishler@dothill.com>) |
Список | pgsql-ports |
> Tom, > > On Thu, Jan 18, 2001 at 12:59:00PM -0500, Tom Lane wrote: > > In current sources I think that you'd get a "cannot unlink" NOTICE, > > but the table would get logically dropped anyway, and the sole > > side-effect would be failure to recover the disk space. But in this > > case we could be talking about large amounts of disk space. > > Cygwin does attempt to overcome the Windows open file issue. If a sharing > violation is detected (i.e., the file is open) during an unlink operation > (really DeleteFile), Cygwin will queue it for deletion later. However, > reading the Cygwin code, I found the following: > > /* FIXME: this delqueue module is very flawed and should be rewritten. > First, having an array of a fixed size for keeping track of the > unlinked but not yet deleted files is bad. Second, some programs > will unlink files and then create a new one in the same location > and this behavior is not supported in the current code. Probably > we should find a move/rename function that will work on open files, > and move delqueue files to some special location or some such > hack... */ > > With the above caveats, is the current functionality sufficient for > PostgreSQL's needs? No, it doesn't seems sufficient, though 7.1 will be a little better because of oid file names. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-ports по дате отправления: