Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXDof-0005uY-W2 for pgsql-hackers@arkaria.postgresql.org; Sun, 11 Sep 2022 03:39:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oXDod-0003EI-Pv for pgsql-hackers@arkaria.postgresql.org; Sun, 11 Sep 2022 03:39:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXDod-0003E9-Dp for pgsql-hackers@lists.postgresql.org; Sun, 11 Sep 2022 03:39:27 +0000 Received: from mail-io1-xd30.google.com ([2607:f8b0:4864:20::d30]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oXDoa-0003mb-26 for pgsql-hackers@lists.postgresql.org; Sun, 11 Sep 2022 03:39:26 +0000 Received: by mail-io1-xd30.google.com with SMTP id h194so2681018iof.4 for ; Sat, 10 Sep 2022 20:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=kIrz5u9bWlJpDwwYa8XToN1QHRukO/GhqD7nOJ1LDCM=; b=rfgNeFGba+8Ii0svMjJkexh6pUa5RdpQWgN3uFcstoQ0lxRS7WDPs04Qkmtk03na54 ySnz884L/ZVZqNVxyxixeRxIYXypWSxbRGO3rmcZmH6eF94kcXFyPlVuyZoMcsq5QibG 5Bj7SGi6duqHiZ3b2idIF6MW41VmjC2XnYu378CLc2JxQsFXKdYsUlVXaCJNAD1KMKAQ p+GMQx8ENuv1PgNryiYvR1XAXQYXjttSFc3mLQtPVeb2xwZDhwcRQPo4r9yJ9LqTs2dC OVhBJdcPRsu3CDoEM9JliKkWu2+jtmEy9S+lTMAnnP9KIy+llZ31Yc3EF2OMlZDVdZyh mCmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=kIrz5u9bWlJpDwwYa8XToN1QHRukO/GhqD7nOJ1LDCM=; b=LUk3dZXL2Z3KB5NvqGmiZgm3ISUAWEAXRz/ee/CWivY6clUj+h/OuxmJp3VR0LYqHP sfWjXGav3IlA7jfeqU5h0MzoIvwWlXPqIqxjEbUcNFH2Q2UHgPb3doEQtar2pkhuQmTR jjCzyk5kcHmblQcHscocxXC+URWnD9SunnxHSWn2c4vDlZhWR5EdGzLaUI/ydlbzXaHC DMCkJuAX7A1XsV+6v7ZGkqeU+RgB5stu1/4LIRRV2swryZE176SC626yV8N6hjBJaRef mNf2WhXTwK1+vP+TaFjJVEpq/pZidCki517Mn+VZAgGDY0S3lDwERc0N0KtIfqLcggNP dUAA== X-Gm-Message-State: ACgBeo28/bWuY0N2rwvkluQkkkT9JCs48jGMrZ0GzTDJDJlHzAAv2wjo qZdN/tGx+c6DqdFQuPGgavKViQ== X-Google-Smtp-Source: AA6agR7hKd5dRyxIQ/zcfT9ofbTRjXmRkn0UXPqqXxNZB+3w6eS/fdHevkBftSWcZUmZiVd+tPfYgQ== X-Received: by 2002:a05:6638:d02:b0:346:f5ef:6ab2 with SMTP id q2-20020a0566380d0200b00346f5ef6ab2mr10997495jaj.300.1662867561766; Sat, 10 Sep 2022 20:39:21 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id e18-20020a0566380cd200b00346e7ca2463sm1833851jak.135.2022.09.10.20.39.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Sep 2022 20:39:21 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id BEB238007E3; Sat, 10 Sep 2022 22:39:19 -0500 (CDT) Date: Sat, 10 Sep 2022 22:39:19 -0500 From: Justin Pryzby To: Michael Paquier Cc: Thomas Munro , Andrew Dunstan , Daniel Gustafsson , Juan =?iso-8859-1?Q?Jos=E9_Santamar=EDa?= Flecha , pgsql-hackers@lists.postgresql.org Subject: Re: Bump MIN_WINNT to 0x0600 (Vista) as minimal runtime in 16~ Message-ID: <20220911033919.GZ31833@telsasoft.com> References: <20220826112637.GD2342@telsasoft.com> <20220908132920.GG31833@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 worth adjusting is ldap_start_tls_sA(), which > would lead to the attached simplification. The MinGW headers list > this routine, so like the previous change I think that it should be > safe for such builds. > > Looking at the buildfarm animals, bowerbird, jacana, fairywren, > lorikeet and drongo disable ldap. hamerkop is the only member that > provides coverage for it, still that's a MSVC build. > > The CI provides coverage for ldap as it is enabled by default and > windows_build_config.pl does not tell otherwise, but with the existing > animals we don't have ldap coverage under MinGW. > > Anyway, I'd like to apply the attached, and I don't quite see why it > would not work after 47bd0b3 under MinGW. Any thoughts? 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). https://cirrus-ci.com/task/6302833585684480 [02:07:57.497] checking whether to build with LDAP support... yes It compiles, which is probably all that matters, and eventually skips the test anyway. [02:23:18.209] [02:23:18] c:/cirrus/src/test/ldap/t/001_auth.pl .. skipped: ldap tests not supported on MSWin32 or dependencies not installed -- Justin