Re: Fix fseek() detection of unseekable files on WIN32 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fix fseek() detection of unseekable files on WIN32
Date
Msg-id ZBb1vFCzhdbHaQQq@paquier.xyz
Whole thread Raw
In response to Re: Fix fseek() detection of unseekable files on WIN32  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Fix fseek() detection of unseekable files on WIN32  (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>)
List pgsql-hackers
On Sun, Mar 19, 2023 at 08:20:27PM +0900, Michael Paquier wrote:
> I am not sure, TBH.  As presented, the two GetFileType() calls in
> _pgftello64() and _pgfseeko64() ignore the case where it returns
> FILE_TYPE_UNKNOWN and GetLastError() has something else than
> NO_ERROR.  The code would return EINVAL for all the errors happening.
> Perhaps that's fine, though I am wondering if we should report
> something more exact, based on _dosmaperr(GetLastError())?

In short, I was thinking among the lines of something like the
attached, where I have invented a pgwin32_get_file_type() that acts as
a wrapper of GetFileType() in a new file called win32common.c, with
all the error handling we would use between fstat(), fseeko() and
ftello() centralized in a single code path.

The refactoring with win32common.c had better be separated into its
own patch, at the end, if using an approach like that.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Jeevan Ladhe
Date:
Subject: server log inflates due to pg_logical_slot_peek_changes/pg_logical_slot_get_changes calls
Next
From: Alexander Lakhin
Date:
Subject: Re: Extending outfuncs support to utility statements