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 1mtC4j-0004qp-PF for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Dec 2021 17:10:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mtC4i-0006kT-D5 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Dec 2021 17:10:20 +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 1mtC4i-0006kJ-3c for pgsql-hackers@lists.postgresql.org; Fri, 03 Dec 2021 17:10:20 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mtC4f-00037q-4L for pgsql-hackers@lists.postgresql.org; Fri, 03 Dec 2021 17:10:19 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1B3HA7Wt2310709; Fri, 3 Dec 2021 12:10:07 -0500 From: Tom Lane To: Peter Eisentraut cc: Andres Freund , Andrew Dunstan , Bruce Momjian , Robert Haas , Alvaro Herrera , PostgreSQL Hackers Subject: Re: pg_dump versus ancient server versions In-reply-to: <196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com> References: <202110222351.3f42l5fgo3lw@alvherre.pgsql> <3783090.1635111977@sss.pgh.pa.us> <3883429.1635171820@sss.pgh.pa.us> <20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de> <22018.1635202338@sss.pgh.pa.us> <20211202221607.xovsdnoh5tpbnhbs@alap3.anarazel.de> <196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com> Comments: In-reply-to Peter Eisentraut message dated "Fri, 03 Dec 2021 17:29:41 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2310707.1638551407.1@sss.pgh.pa.us> Date: Fri, 03 Dec 2021 12:10:07 -0500 Message-ID: <2310708.1638551407@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > [ policy requiring that 9.2 and up be kept buildable, as of today ] I experimented to see what this would entail exactly. Using current macOS (Apple clang version 13.0.0) on M1 hardware, I built with minimal configure options (--enable-debug --enable-cassert) and ran the core regression tests. I found that commit 1c0cf52b3 (Use return instead of exit() in configure) is needed in 9.4 and before, else we don't get through configure. That's the only fix needed to get a clean build in 9.4 and 9.3. 9.2 shows several compiler warnings, the scarier ones of which could be cleaned up by back-patching c74d586d2 (Fix function return type confusion). The remainder are variable-may-be-used-uninitialized warnings, which I think people are accustomed to ignoring in dubious cases. In any case, I failed to get rid of them without back-patching 71450d7fd (Teach compiler that ereport(>=ERROR) does not return), which seems like a bridge too far. I also tried 9.1, but it has multiple compile-time problems: * fails to select a spinlock implementation * "conflicting types for 'base_yylex'" * strange type-conflict warnings in zlib calls So at least on this platform, there are solid technical reasons to select 9.2 not 9.1 as the cutoff. Obviously, we might find some other things to fix if we checked with other compilers, or tested more than the core tests. But this much seems quite doable, and it's probably prerequisite for any further testing. regards, tom lane