Bump MIN_WINNT to 0x0600 (Vista) as minimal runtime in 16~
Hi all,
On the thread about the removal of VS 2013, Jose (in CC) has mentioned
that bumping MIN_WINNT independently would make sense, as the
simplication of locales would expose under MinGW some code for
GetLocaleInfoEx():
/messages/by-id/CAC+AXB3himFH+-pGRO1cYju6zF2hLH6VmwPbf5RAytF1UBm_nw@mail.gmail.com
Attached is a patch to set MIN_WINNT, the minimal version of Windows
allowed at run-time to 0x0600 for all environments, aka Vista. This
results in removing the support for XP at run-time when compiling with
anything else than VS >= 2015 (VS 2013, MinGW, etc.). We could cut
things more, I hope, but this bump makes sense in itself with the
business related to locales.
What I would like to do is to apply that at the beginning of the dev
cycle for v16, in parallel of the removal of VS 2013. This move is
rather independent of the other thread, which is why I am spawning a
new one here. And it is better than having to dig into the other
thread for a change like that.
Thoughts or opinions?
--
Michael
Attachments:
0001-Bump-WIN_MINNT-to-0x0600-everywhere.patchtext/x-diff; charset=us-asciiDownload+6-11
On Thu, May 26, 2022 at 2:59 PM Michael Paquier <michael@paquier.xyz> wrote:
On the thread about the removal of VS 2013, Jose (in CC) has mentioned
that bumping MIN_WINNT independently would make sense, as the
simplication of locales would expose under MinGW some code for
GetLocaleInfoEx():
/messages/by-id/CAC+AXB3himFH+-pGRO1cYju6zF2hLH6VmwPbf5RAytF1UBm_nw@mail.gmail.comAttached is a patch to set MIN_WINNT, the minimal version of Windows
allowed at run-time to 0x0600 for all environments, aka Vista. This
results in removing the support for XP at run-time when compiling with
anything else than VS >= 2015 (VS 2013, MinGW, etc.). We could cut
things more, I hope, but this bump makes sense in itself with the
business related to locales.What I would like to do is to apply that at the beginning of the dev
cycle for v16, in parallel of the removal of VS 2013. This move is
rather independent of the other thread, which is why I am spawning a
new one here. And it is better than having to dig into the other
thread for a change like that.Thoughts or opinions?
I think we should drop everything older than Win 10 for PG16, as
argued in various threads where various pain points came up. For one
thing, that would make a lot of future work simpler (ie not needing to
test alternative code paths on dead computers without CI or BF, AKA
dead code), and also I don't think we really help anyone by allowing
new database deployments on operating systems that aren't receiving
vendor patches on the world's most attacked operating system. Doing
it incrementally is fine by me, too, though, if it makes the patches
and discussions easier...
On Thu, May 26, 2022 at 04:16:40PM +1200, Thomas Munro wrote:
I think we should drop everything older than Win 10 for PG16, as
argued in various threads where various pain points came up. For one
thing, that would make a lot of future work simpler (ie not needing to
test alternative code paths on dead computers without CI or BF, AKA
dead code), and also I don't think we really help anyone by allowing
new database deployments on operating systems that aren't receiving
vendor patches on the world's most attacked operating system. Doing
it incrementally is fine by me, too, though, if it makes the patches
and discussions easier...
Is there anything posted recently that would require that? Perhaps
the async work? FWIW, I agree to be much more aggressive, but there
is nothing in the tree now that depends on _WIN32_WINNT, except one
change for the locales.
--
Michael
On Thu, May 26, 2022 at 6:27 AM Michael Paquier <michael@paquier.xyz> wrote:
Is there anything posted recently that would require that? Perhaps
the async work? FWIW, I agree to be much more aggressive, but there
is nothing in the tree now that depends on _WIN32_WINNT, except one
change for the locales.
There have been a couple of discussions involving not only Windows
version10, but also the Release id:
https://commitfest.postgresql.org/38/3347/
https://commitfest.postgresql.org/38/3530/
/messages/by-id/6389b5a88e114bee85593af2853c08cd@dental-vision.de
Maybe this thread can push those others forward.
Regards,
Juan José Santamaría Flecha
Show quoted text
On Thu, May 26, 2022 at 4:27 PM Michael Paquier <michael@paquier.xyz> wrote:
Perhaps the async work?
(Checks code...) Looks like the experimental Windows native AIO code
we have today, namely io_method=windows_iocp, only needs Vista.
That's for GetQueueCompletionStatusEx() (before that you had to call
GetQueuedCompletionStatus() in a loop to read multiple IO completion
events from an IOCP), and otherwise it's all just ancient Windows
"overlapped" stuff. Not sure if we'll propose that io_method, or skip
directly to the new io_uring-style API that appeared in Win 11 (not
yet tried), or propose both as long as Win 10 is around, or ... I
dunno.
On Thu, May 26, 2022 at 10:17:08AM +0200, Juan José Santamaría Flecha wrote:
There have been a couple of discussions involving not only Windows
version10, but also the Release id:
This mentions 0x0A00, aka Windows 10, for atomic rename support.
Similarly 0x0A00, aka Windows 10, for fdatasync().
/messages/by-id/6389b5a88e114bee85593af2853c08cd@dental-vision.de
And Windows 10 1703, for large pages.
Maybe this thread can push those others forward.
Post Windows 8, the most annoying part is that manifests are required
to be able to check at run-time on which version you are running with
routines like IsWindowsXXOrGreater() if you compiled with a threshold
of MIN_WINNT lower than the version you expect compatibility for.
And each one of those things would mean cutting a lot of past support
if we want to eliminate the manifest part. Windows 8 ends its support
in 2023, it seems, so that sounds short even for PG16.
--
Michael
On Fri, May 27, 2022 at 3:53 PM Michael Paquier <michael@paquier.xyz> wrote:
Windows 8 ends its support
in 2023, it seems, so that sounds short even for PG16.
I guess you meant 8.1 here, and corresponding server release 2012 R2.
These will come to the end of their "extended" support phase in 2023,
before PG16 comes out. If I understand correctly (and I'm not a
Windows user, I just googled this), they will start showing blue
full-screen danger-Will-Robinson alerts about viruses and malware.
Why would we have explicit support for that in a new release? Do we
want people putting their users' data in such a system? Can you go to
GDPR jail for that in Europe? (Joking, I think).
We should go full Marie Kondo on EOL'd OSes that are not in our CI or
build farm, IMHO.
On 27 May 2022, at 23:07, Thomas Munro <thomas.munro@gmail.com> wrote:
We should go full Marie Kondo on EOL'd OSes that are not in our CI or
build farm, IMHO.
FWIW, +1
--
Daniel Gustafsson https://vmware.com/
On Sat, May 28, 2022 at 05:30:51PM +0200, Daniel Gustafsson wrote:
On 27 May 2022, at 23:07, Thomas Munro <thomas.munro@gmail.com> wrote:
We should go full Marie Kondo on EOL'd OSes that are not in our CI or
build farm, IMHO.FWIW, +1
Okay, I am outnumbered, and that would mean bumping MIN_WINNT to
0x0A00. So, ready to move to this version at full speed for 16? We
still have a couple of weeks ahead before the next dev cycle begins,
so feel free to comment, of course.
--
Michael
On Mon, May 30, 2022 at 03:59:52PM +0900, Michael Paquier wrote:
Okay, I am outnumbered, and that would mean bumping MIN_WINNT to
0x0A00. So, ready to move to this version at full speed for 16? We
still have a couple of weeks ahead before the next dev cycle begins,
so feel free to comment, of course.
And attached is an updated patch to do exactly that.
--
Michael
Attachments:
v2-0001-Bump-WIN_MINNT-to-0x0A00-everywhere-Windows-10.patchtext/x-diff; charset=us-asciiDownload+6-12
On Thu, Jun 9, 2022 at 3:55 PM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, May 30, 2022 at 03:59:52PM +0900, Michael Paquier wrote:
Okay, I am outnumbered, and that would mean bumping MIN_WINNT to
0x0A00. So, ready to move to this version at full speed for 16? We
still have a couple of weeks ahead before the next dev cycle begins,
so feel free to comment, of course.And attached is an updated patch to do exactly that.
<productname>PostgreSQL</productname> can be expected to work on
these operating
- systems: Linux (all recent distributions), Windows (XP and later),
+ systems: Linux (all recent distributions), Windows (10 and later),
FreeBSD, OpenBSD, NetBSD, macOS, AIX, HP/UX, and Solaris.Cool. (I'm not sure what "all recent distributions" contributes but
that's not from your patch...).
The Cygwin stuff in installation.sgml also mentions NT, 2000, XP, but
it's not clear from the phrasing if it meant "and later" or "and
earlier", so I'm not sure if it needs adjusting or removing...
While looking for more stuff to vacuum, I found this:
<title>Special Considerations for 64-Bit Windows</title>
<para>
PostgreSQL will only build for the x64 architecture on 64-bit Windows, there
is no support for Itanium processors.
</para>
I think we can drop mention of Itanium (RIP): the ancient versions of
Windows that could run on that arch are desupported with your patch.
It might be more relevant to say that we can't yet run on ARM, and
Windows 11 is untested by us, but let's fix those problems instead of
documenting them :-)
Is the mention of "64-Bit" in that title sounds a little anachronistic
to me (isn't that the norm now?) but I'm not sure what to suggest.
There are more mentions of older Windows releases near the compiler
stuff but perhaps your MSVC version vacuuming work will take care of
those.
On Thu, Jun 09, 2022 at 04:55:45PM +1200, Thomas Munro wrote:
The Cygwin stuff in installation.sgml also mentions NT, 2000, XP, but
it's not clear from the phrasing if it meant "and later" or "and
earlier", so I'm not sure if it needs adjusting or removing...
Right. We could just remove the entire mention to "NT, 2000 or XP"
instead? There would be no loss in clarity IMO.
I think we can drop mention of Itanium (RIP): the ancient versions of
Windows that could run on that arch are desupported with your patch.
It might be more relevant to say that we can't yet run on ARM, and
Windows 11 is untested by us, but let's fix those problems instead of
documenting them :-)
Okay to remove the Itanium part for me.
Is the mention of "64-Bit" in that title sounds a little anachronistic
to me (isn't that the norm now?) but I'm not sure what to suggest.
Not sure. I think that I would leave this part alone for now.
There are more mentions of older Windows releases near the compiler
stuff but perhaps your MSVC version vacuuming work will take care of
those.
Yes, I have a few changes like the one in main.c for _M_AMD64. Are
you referring to something else?
--
Michael
On Thu, Jun 09, 2022 at 02:47:36PM +0900, Michael Paquier wrote:
On Thu, Jun 09, 2022 at 04:55:45PM +1200, Thomas Munro wrote:
I think we can drop mention of Itanium (RIP): the ancient versions of
Windows that could run on that arch are desupported with your patch.
It might be more relevant to say that we can't yet run on ARM, and
Windows 11 is untested by us, but let's fix those problems instead of
documenting them :-)Okay to remove the Itanium part for me.
install-windows.sgml has one extra spot mentioning Windows 7 and
Server 2008 that can be simplified on top of that.
There are more mentions of older Windows releases near the compiler
stuff but perhaps your MSVC version vacuuming work will take care of
those.Yes, I have a few changes like the one in main.c for _M_AMD64. Are
you referring to something else?
Actually, this can go with the bump of MIN_WINNT as it uses one of the
IsWindows*OrGreater() macros as a runtime check. And there are two
more places in pg_ctl.c that can be similarly cleaned up.
It is possible that I have missed some spots, of course.
--
Michael
Attachments:
v3-0001-Bump-WIN_MINNT-to-0x0A00-everywhere-Windows-10.patchtext/x-diff; charset=us-asciiDownload+13-64
On Thu, Jun 16, 2022 at 03:14:16PM +0900, Michael Paquier wrote:
Actually, this can go with the bump of MIN_WINNT as it uses one of the
IsWindows*OrGreater() macros as a runtime check. And there are two
more places in pg_ctl.c that can be similarly cleaned up.It is possible that I have missed some spots, of course.
It does not seem to be the case on a second look. The buildfarm
animals running Windows are made of:
- hamerkop, Windows server 2016 (based on Win10 AFAIK)
- drongo, Windows server 2019
- bowerbird, Windows 10 pro
- jacana, Windows 10
- fairywren, Msys server 2019
- bichir, Ubuntu/Windows 10 mix
Now that v16 is open for business, any objections to move on with this
patch and bump MIN_WINNT to 0x0A00 on HEAD? There are follow-up items
for large pages and more.
--
Michael
On Wed, Jul 6, 2022 at 7:28 PM Michael Paquier <michael@paquier.xyz> wrote:
On Thu, Jun 16, 2022 at 03:14:16PM +0900, Michael Paquier wrote:
Actually, this can go with the bump of MIN_WINNT as it uses one of the
IsWindows*OrGreater() macros as a runtime check. And there are two
more places in pg_ctl.c that can be similarly cleaned up.It is possible that I have missed some spots, of course.
It does not seem to be the case on a second look. The buildfarm
animals running Windows are made of:
- hamerkop, Windows server 2016 (based on Win10 AFAIK)
- drongo, Windows server 2019
- bowerbird, Windows 10 pro
- jacana, Windows 10
- fairywren, Msys server 2019
- bichir, Ubuntu/Windows 10 mixNow that v16 is open for business, any objections to move on with this
patch and bump MIN_WINNT to 0x0A00 on HEAD? There are follow-up items
for large pages and more.
+1 for proceeding. This will hopefully unblock a few things, and it's
good to update our claims to match the reality of what we are actually
testing and able to debug.
The build farm also has frogmouth and currawong, 32 bit systems
running Windows XP, but they are only testing REL_10_STABLE so I
assume Andrew will decommission them in November.
On 2022-07-06 We 16:46, Thomas Munro wrote:
On Wed, Jul 6, 2022 at 7:28 PM Michael Paquier <michael@paquier.xyz> wrote:
On Thu, Jun 16, 2022 at 03:14:16PM +0900, Michael Paquier wrote:
Actually, this can go with the bump of MIN_WINNT as it uses one of the
IsWindows*OrGreater() macros as a runtime check. And there are two
more places in pg_ctl.c that can be similarly cleaned up.It is possible that I have missed some spots, of course.
It does not seem to be the case on a second look. The buildfarm
animals running Windows are made of:
- hamerkop, Windows server 2016 (based on Win10 AFAIK)
- drongo, Windows server 2019
- bowerbird, Windows 10 pro
- jacana, Windows 10
- fairywren, Msys server 2019
- bichir, Ubuntu/Windows 10 mixNow that v16 is open for business, any objections to move on with this
patch and bump MIN_WINNT to 0x0A00 on HEAD? There are follow-up items
for large pages and more.+1 for proceeding. This will hopefully unblock a few things, and it's
good to update our claims to match the reality of what we are actually
testing and able to debug.The build farm also has frogmouth and currawong, 32 bit systems
running Windows XP, but they are only testing REL_10_STABLE so I
assume Andrew will decommission them in November.
Yeah, it's not capable of supporting anything newer, so it will finally
go to sleep this year.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Wed, Jul 06, 2022 at 05:13:27PM -0400, Andrew Dunstan wrote:
On 2022-07-06 We 16:46, Thomas Munro wrote:
The build farm also has frogmouth and currawong, 32 bit systems
running Windows XP, but they are only testing REL_10_STABLE so I
assume Andrew will decommission them in November.Yeah, it's not capable of supporting anything newer, so it will finally
go to sleep this year.
Okay, thanks for confirming. I think that I'll give it a try today
then, my schedule would fit nicely with the buildfarm monitoring.
--
Michael
On Thu, Jul 07, 2022 at 09:11:57AM +0900, Michael Paquier wrote:
Okay, thanks for confirming. I think that I'll give it a try today
then, my schedule would fit nicely with the buildfarm monitoring.
And I have applied that, after noticing that the MinGW was complaining
because _WIN32_WINNT was not getting set like previously and removing
_WIN32_WINNT as there is no need for it anymore. The CI has reported
green for all my tests, so I am rather confident to not have messed up
something. Now, let's see what the buildfarm members tell. This
should take a couple of hours..
--
Michael
On Thu, Jul 07, 2022 at 01:56:39PM +0900, Michael Paquier wrote:
And I have applied that, after noticing that the MinGW was complaining
because _WIN32_WINNT was not getting set like previously and removing
_WIN32_WINNT as there is no need for it anymore. The CI has reported
green for all my tests, so I am rather confident to not have messed up
something. Now, let's see what the buildfarm members tell. This
should take a couple of hours..
Since this has been applied, all the Windows members have reported a
green state except for jacana and bowerbird. Based on their
environment, I would not expect any issues though I may be wrong.
Andrew, is something happening on those environments? Is 495ed0e
causing problems?
--
Michael
On Thu, Jul 07, 2022 at 01:56:39PM +0900, Michael Paquier wrote:
On Thu, Jul 07, 2022 at 09:11:57AM +0900, Michael Paquier wrote:
Okay, thanks for confirming. I think that I'll give it a try today
then, my schedule would fit nicely with the buildfarm monitoring.And I have applied that, after noticing that the MinGW was complaining
because _WIN32_WINNT was not getting set like previously and removing
_WIN32_WINNT as there is no need for it anymore. The CI has reported
green for all my tests, so I am rather confident to not have messed up
something. Now, let's see what the buildfarm members tell. This
should take a couple of hours..
If I'm not wrong, there's some lingering comments which could be removed since
495ed0ef2.
src/bin/pg_ctl/pg_ctl.c: * on NT4. That way, we don't break on NT4.
src/bin/pg_ctl/pg_ctl.c: * On NT4, or any other system not containing the required functions, will
src/bin/pg_ctl/pg_ctl.c: * NT4 doesn't have CreateRestrictedToken, so just call ordinary
src/port/dirmod.c: * Win32 (NT4 and newer).
src/backend/port/win32/socket.c: /* No error, zero bytes (win2000+) or error+WSAEWOULDBLOCK (<=nt4) */
--
Justin