> 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