Re: Atomic rename feature for Windows.

From: Victor Spirin <v(dot)spirin(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Atomic rename feature for Windows.
Date: 2021-09-06 17:44:43
Message-ID: 719640c1-b0e8-6cc7-0c70-5d1d5c3a2fa7@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello.

I have changed the way I add the manifest to projects. I used the
AdditionalManifestFiles option for a VS project.

Victor Spirin
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company

08.07.2021 1:32, Victor Spirin пишет:
> Thanks!
>
> In this version of the patch, calls to malloc have been removed.
> Hopefully MAX_PATH is long enough for filenames.
>
>> How does that cope with durable_rename_excl() where rename() is used
>> on Windows?  The problems that 909b449 has somewhat "fixed" were
>> annoying for the users as it prevented WAL segment recycling, so we
>> need to be sure that this does not cause more harm.
>
> I tested this patch to resolve the error message "could not rename
> temporary statistics file "pg_stat_tmp/pgstat.tmp" to
> "pg_stat_tmp/pgstat.stat": Permission denied".  (I have a patch
> option to rename a temporary file for statistics only.)
>
>>> + /*
>>> + * CHECKSUM_TYPE_NONE defined in the winioctl.h when _WIN32_WINNT
>>> >= _WIN32_WINNT_WIN10
>>> + */
>>> +#ifdef CHECKSUM_TYPE_NONE
>>> +#undef CHECKSUM_TYPE_NONE
>>> +#endif
>> Okay.  Should this be renamed separately then to avoid conflicts?
>>
> Renaming CHECKSUM_TYPE_NONE in the  checksum_helper.h is the best way
> to go.
>
>>   #if defined(_MSC_VER) && _MSC_VER >= 1900
>> -#define MIN_WINNT 0x0600
>> +#define MIN_WINNT 0x0A00
>>   #else
>>   #define MIN_WINNT 0x0501
>>   #endif
>> This is a large bump for Studio >= 2015 I am afraid.  That does not
>> seem acceptable, as it means losing support for GetLocaleInfoEx()
>> across older versions.
>>
> It seems that the MIN_WINNT value 0x0600 or 0x0A00 does not affect the
> use of the GetLocaleInfoEx () function
>
>>> +        # manifest with ms_compatibility:supportedOS tags for using
>>> IsWindows10OrGreater() function
>>> +        print $o "\n1 24 \"src/port/win10.manifest\"\n";
>>> +
>>>           close($o);
>>>           close($i);
>>>       }
>>> diff --git a/src/port/win10.manifest b/src/port/win10.manifest
>>> new file mode 100644
>> It would be good to not require that.  Those extra files make the
>> long-term maintenance harder.
> Function IsWindows10OrGreater() working properly if there is manifest
> with <ms_compatibility:supportedOS
> Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
>
> "Applications not manifested for Windows 10 return false, even if the
> current operating system version is Windows 10."
>
>
> Victor Spirin
> Postgres Professional:http://www.postgrespro.com
> The Russian Postgres Company
>
> 06.07.2021 4:43, Michael Paquier пишет:
>> On Mon, Jul 05, 2021 at 04:53:06PM +0300, Victor Spirin wrote:
>>> This patch related to this post:
>>> https://www.postgresql.org/message-id/CAEepm%3D0FV-k%2B%3Dd9z08cW%3DZXoR1%3Dkw9wdpkP6WAuOrKJdz-8ujg%40mail.gmail.com
>>>
>> How does that cope with durable_rename_excl() where rename() is used
>> on Windows?  The problems that 909b449 has somewhat "fixed" were
>> annoying for the users as it prevented WAL segment recycling, so we
>> need to be sure that this does not cause more harm.
>>
>>> + /*
>>> + * CHECKSUM_TYPE_NONE defined in the winioctl.h when _WIN32_WINNT
>>> >= _WIN32_WINNT_WIN10
>>> + */
>>> +#ifdef CHECKSUM_TYPE_NONE
>>> +#undef CHECKSUM_TYPE_NONE
>>> +#endif
>> Okay.  Should this be renamed separately then to avoid conflicts?
>>
>>> - * get support for GetLocaleInfoEx() with locales. For everything else
>>> + * Studio 2015 the minimum requirement is Windows 10 (0x0A00) to
>>> get support for SetFileInformationByHandle.
>>> + * The minimum requirement is Windows Vista (0x0600) get support
>>> for GetLocaleInfoEx() with locales.
>>> + * For everything else
>>>    * the minimum version is Windows XP (0x0501).
>>>    */
>>>   #if defined(_MSC_VER) && _MSC_VER >= 1900
>>> -#define MIN_WINNT 0x0600
>>> +#define MIN_WINNT 0x0A00
>>>   #else
>>>   #define MIN_WINNT 0x0501
>>>   #endif
>> This is a large bump for Studio >= 2015 I am afraid.  That does not
>> seem acceptable, as it means losing support for GetLocaleInfoEx()
>> across older versions.
>>
>>> +#if defined(WIN32) && !defined(__CYGWIN__) &&
>>> defined(_WIN32_WINNT_WIN10) && _WIN32_WINNT >= _WIN32_WINNT_WIN10
>>> +
>>> +#include <versionhelpers.h>
>>> +
>>> +/*
>>> + * win10_rename - uses SetFileInformationByHandle function with
>>> FILE_RENAME_FLAG_POSIX_SEMANTICS flag for atomic rename file
>>> + * working only on Windows 10 or later and  _WIN32_WINNT must be >=
>>> _WIN32_WINNT_WIN10
>>> + */
>>> +static int win10_rename(wchar_t const* from, wchar_t const* to)
>> Having win10_rename(), a wrapper for pgrename_win10(), which is itself
>> an extra wrapper for pgrename(), is confusing.  Could you reduce the
>> layers of functions here.  At the end we just want an extra runtime
>> option for pgrename().  Note that pgrename_win10() could be static to
>> dirmod.c, and it seems to me that you just want a small function to do
>> the path conversion anyway.  It would be better to avoid using
>> malloc() in those code paths as well, as the backend could finish by
>> calling that.  We should be able to remove the malloc()s with local
>> variables large enough to hold those paths, no?
>>
>>> +        # manifest with ms_compatibility:supportedOS tags for using
>>> IsWindows10OrGreater() function
>>> +        print $o "\n1 24 \"src/port/win10.manifest\"\n";
>>> +
>>>           close($o);
>>>           close($i);
>>>       }
>>> diff --git a/src/port/win10.manifest b/src/port/win10.manifest
>>> new file mode 100644
>> It would be good to not require that.  Those extra files make the
>> long-term maintenance harder.
>> --
>> Michael

Attachment Content-Type Size
rename_atomic3.patch text/plain 7.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-09-06 17:51:52 Re: Column Filtering in Logical Replication
Previous Message Fujii Masao 2021-09-06 17:34:17 Re: pgbench bug candidate: negative "initial connection time"