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

Re: fsync with sync, and Win32 unlink

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: fsync with sync, and Win32 unlink
Date: 2004-03-13 03:55:56
Message-ID: 14831.1079150156@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
> Tom Lane wrote:
>> So unless I'm totally misunderstanding where you mean to use 
>> this code, I don't see the point.

> I think you might be.

> I'm not suggesting that we modify file creation to allow overwrite. The
> suggestion is that we modify file creation to allow delete. Win32 _open()
> call opens files in a manner that does not allow them to be deleted when
> held by another process. However, "replacing" the open() call with an
> orchestrated call to CreateFile/_open_osfhandle appears to give us exactly
> that behaviour we expect from open() under *nix (specifically, being able to
> unlink a file held by another process).

Hmm ... so you're suggesting that if every open() that can ever open a
Postgres file is replaced by this win32_open() code, then unlink()ing
the file will behave as per Unix custom?  Presumably, if we miss even
one open(), or some random admin is more'ing a file when we try to
delete it, the database crashes?

This strikes me as pretty damn fragile, but then every part of Windoze
is pretty damn fragile.  If it works as you say then it's good enough
for me, because I'm not ever going to buy into the premise that Postgres
on Windows is a production-grade setup.

			regards, tom lane

In response to

pgsql-hackers-win32 by date

Next:From: Claudio NatoliDate: 2004-03-13 05:07:34
Subject: Re: fsync with sync, and Win32 unlink
Previous:From: Tyler MitchellDate: 2004-03-13 00:44:50
Subject: Re: no rule to make target dynloader.o

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