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 |
Message-ID: | ZBb1vFCzhdbHaQQq@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
v3-0001-fix-fseek-detection-of-unseekable-files-for-WIN32.patch | text/x-diff | 8.4 KB |
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 |