Re: Fix fseek() detection of unseekable files on WIN32

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix fseek() detection of unseekable files on WIN32
Date: 2023-03-19 11:45:00
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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.

Attachment Content-Type Size
v3-0001-fix-fseek-detection-of-unseekable-files-for-WIN32.patch text/x-diff 8.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2023-03-19 12:00:01 Re: Extending outfuncs support to utility statements
Previous Message Jeevan Ladhe 2023-03-19 11:29:17 server log inflates due to pg_logical_slot_peek_changes/pg_logical_slot_get_changes calls