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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers-win32 by date

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