On Mon, May 15, 2023 at 03:22:29PM +1200, Thomas Munro wrote:
> LGTM.
Thanks, fixed!
--
Michael
signature.asc
Description: PGP signature
On Mon, May 15, 2023 at 2:57 PM Michael Paquier wrote:
> On Mon, May 15, 2023 at 02:08:32PM +1200, Thomas Munro wrote:
> > After 495ed0e, do these references to Windows SDK 8.1 still make sense?
> As listed on https://en.wikipedia.org/wiki/Microsoft_Windows_SDK,
> likely not. What do you think a
On Mon, May 15, 2023 at 02:08:32PM +1200, Thomas Munro wrote:
> After 495ed0e, do these references to Windows SDK 8.1 still make sense?
>
> src/sgml/install-windows.sgml: as well as standalone Windows SDK
> releases 8.1a to 10.
> src/sgml/install-windows.sgml: Microsoft Windows
> SDK version 8.1
After 495ed0e, do these references to Windows SDK 8.1 still make sense?
src/sgml/install-windows.sgml: as well as standalone Windows SDK
releases 8.1a to 10.
src/sgml/install-windows.sgml: Microsoft Windows
SDK version 8.1a to 10 or
On Mon, Sep 12, 2022 at 09:42:25AM +1200, Thomas Munro wrote:
> When looking the function up it made sense to use the name ending in
> '...A', but when calling directly I think we shouldn't use the A
> suffix, we should let the macros do that for us[1]. (I
> wondered for a moment if that would ev
On Sun, Sep 11, 2022 at 12:29 PM Michael Paquier wrote:
> On Fri, Sep 09, 2022 at 08:11:09PM +0900, Michael Paquier wrote:
> > Based on what I can see, the Windows animals seem to have digested
> > 47bd0b3 (cygwin, MinGW and MSVC), so I think that we are good.
Great, that's a lot of nice cleanup.
On Sat, Sep 10, 2022 at 10:39:19PM -0500, Justin Pryzby wrote:
> There's a CF entry to add it, and I launched it with your patch.
> (This is in a branch which already has that, and also does a few other
> things differently).
No need for a CF entry if you want to play with the tree. I have
Cirrus
On Sun, Sep 11, 2022 at 09:28:54AM +0900, Michael Paquier wrote:
> On Fri, Sep 09, 2022 at 08:11:09PM +0900, Michael Paquier wrote:
> > Based on what I can see, the Windows animals seem to have digested
> > 47bd0b3 (cygwin, MinGW and MSVC), so I think that we are good.
>
> The last part that's wor
On Fri, Sep 09, 2022 at 08:11:09PM +0900, Michael Paquier wrote:
> Based on what I can see, the Windows animals seem to have digested
> 47bd0b3 (cygwin, MinGW and MSVC), so I think that we are good.
The last part that's worth adjusting is ldap_start_tls_sA(), which
would lead to the attached simpl
On Fri, Sep 09, 2022 at 10:55:55AM +0900, Michael Paquier wrote:
> Thanks. This set of simplifications is too good to let go, and I have
> a window to look after the buildfarm today and tomorrow, which should
> be enough to take action if need be. Hence, I have applied the
> patch. Now, let's se
On Thu, Sep 08, 2022 at 08:29:20AM -0500, Justin Pryzby wrote:
> It seems silly to do it at runtime if it's possible to do it at link time.
Thanks. This set of simplifications is too good to let go, and I have
a window to look after the buildfarm today and tomorrow, which should
be enough to take
On Thu, Sep 08, 2022 at 05:55:40PM +0900, Michael Paquier wrote:
> On Tue, Aug 30, 2022 at 01:29:24PM +1200, Thomas Munro wrote:
> > This reminds me of 24c3ce8f1, which replaced a dlopen()-ish thing with
> > a direct function call. Can you just call all these functions
> > directly these days?
>
On Tue, Aug 30, 2022 at 01:29:24PM +1200, Thomas Munro wrote:
> This reminds me of 24c3ce8f1, which replaced a dlopen()-ish thing with
> a direct function call. Can you just call all these functions
> directly these days?
Hmm. Some tests in the CI show that attempting to call directly
MiniDumpWr
On Tue, Aug 30, 2022 at 12:57 PM Michael Paquier wrote:
> On Sat, Aug 27, 2022 at 02:35:25PM +0900, Michael Paquier wrote:
> > There may be a point in enforcing CreateProcess() if
> > CreateRestrictedToken() cannot be loaded, but that would be a security
> > issue if Windows goes crazy as we shoul
On Sat, Aug 27, 2022 at 02:35:25PM +0900, Michael Paquier wrote:
> There may be a point in enforcing CreateProcess() if
> CreateRestrictedToken() cannot be loaded, but that would be a security
> issue if Windows goes crazy as we should always expect the function,
> so this had better return an erro
On Fri, Aug 26, 2022 at 06:26:37AM -0500, Justin Pryzby wrote:
> If I'm not wrong, there's some lingering comments which could be removed since
> 495ed0ef2.
It seems to me that you are right. I have not thought about looking
at references to NT. Good catches!
> src/bin/pg_ctl/pg_ctl.c: * on NT4
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 t
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 m
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
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.
>
On 2022-07-06 We 16:46, Thomas Munro wrote:
> On Wed, Jul 6, 2022 at 7:28 PM Michael Paquier 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.
On Wed, Jul 6, 2022 at 7:28 PM Michael Paquier 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 th
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
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 relev
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
On Thu, Jun 9, 2022 at 3:55 PM Michael Paquier 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 ah
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
On Sat, May 28, 2022 at 05:30:51PM +0200, Daniel Gustafsson wrote:
> On 27 May 2022, at 23:07, Thomas Munro 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.
> On 27 May 2022, at 23:07, Thomas Munro 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 Fri, May 27, 2022 at 3:53 PM Michael Paquier 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 come
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:
>
> https://commitfest.postgresql.org/38/3347/
This mentions 0x0A00, aka Windows 10, for atomic rename support.
On Thu, May 26, 2022 at 4:27 PM Michael Paquier 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
GetQueuedCompl
On Thu, May 26, 2022 at 6:27 AM Michael Paquier 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.
T
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 p
On Thu, May 26, 2022 at 2:59 PM Michael Paquier 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():
> https://www.postgr
35 matches
Mail list logo
