On Tue, Sep 27, 2022 at 10:27 AM Nathan Bossart <nathandboss...@gmail.com> wrote: > On Mon, Sep 26, 2022 at 08:33:53PM +0530, Bharath Rupireddy wrote: > > Irrespective of what Windows does with file pointers in WriteFile(), > > should we add lseek(SEEK_SET) in our own pwrite()'s implementation, > > something like [5]? This is rather hackish without fully knowing what > > Windows does internally in WriteFile(), but this does fix inherent > > issues that our pwrite() callers (there are quite a number of places > > that use pwrite() and presumes file pointer doesn't change on Windows) > > may have on Windows. See the regression tests passing [6] with the fix > > [5]. > > I think so. I don't see why we would rather have each caller ensure > pwrite() behaves as documented.
I don't think so, that's an extra kernel call. I think I'll just have to revert part of my recent change that removed the pg_ prefix from those function names in our code, and restore the comment that warns you about the portability hazard (I thought it went away with HP-UX 10, where we were literally calling lseek() before every write()). The majority of users of these functions don't intermix them with calls to read()/write(), so they don't care about the file position, so I think it's just something we'll have to continue to be mindful of in the places that do. Unless, that is, I can find a way to stop it from doing that... I've added this to my Windows to-do list. I am going to have a round of Windows hacking quite soon.
