From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
Date: Fri, 03 Dec 2021 13:09:31 -0500
Message-ID: <2314554.1638554971@sss.pgh.pa.us> (raw)
In-Reply-To: <a18fa641-88b8-257e-5848-135a397d6e4d@dunslane.net>
References: <CA+TgmoboH6=SgWHPddv_8ie91Qf2ECKSvg-72aYajKb2gyLYQg@mail.gmail.com>
<202110222351.3f42l5fgo3lw@alvherre.pgsql>
<CA+TgmobB8cj30z6dzEf5xNTxzGRNGmkJsCr3nv_Hneo0o5kozg@mail.gmail.com>
<3783090.1635111977@sss.pgh.pa.us>
<CA+TgmobQxeGVtgxQz_OxdgCO4r=Tb2SaCh9FJ8Dxjaq9DxHH_g@mail.gmail.com>
<3883429.1635171820@sss.pgh.pa.us>
<20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de>
<c51ede27-3b6d-1d27-9d1a-227526858db2@dunslane.net>
<22018.1635202338@sss.pgh.pa.us>
<d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com>
<20211202221607.xovsdnoh5tpbnhbs@alap3.anarazel.de>
<196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com>
<2310708.1638551407@sss.pgh.pa.us>
<a18fa641-88b8-257e-5848-135a397d6e4d@dunslane.net>
Andrew Dunstan <andrew@dunslane.net> writes:
> On 12/3/21 12:10, Tom Lane wrote:
>> 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've mentioned my efforts on fedora previously. But like you I used a
> minimal configuration. So what would be reasonable to test? I know you
> mentioned building with perl and python upthread so we could possibly
> test transforms. Anything else? I don't think we need to worry about all
> the authentication-supporting options. XML/XSLT maybe.
Not sure. I think we should evaluate based on
1. how integral is the option, ie how much PG code can't we test if
we don't enable it.
2. how stable is the referenced code.
Point 2 makes me want to exclude both Python and OpenSSL, as they've
both proven to be moving API targets. If we want to have tests for
transform modules, plperl would be sufficient for that, and perl seems
to be a lot more stable than python. libxml is pretty morib^H^H^Hstable,
but on the other hand it seems quite noncritical for the sorts of tests
we want to run against old servers, so I'd be inclined to exclude it.
Looking through the other configure options, the only one that I find
to be a hard call is --enable-nls. In theory this shouldn't be
critical for testing pg_dump or psql ... but you never know, and it
hasn't been a stability problem. Every other one I think we could
ignore for these purposes. At some point --with-icu might become
interesting, but it isn't yet relevant to any out-of-support
branches, so we can leave that call for another day.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@dunslane.net, peter.eisentraut@enterprisedb.com, andres@anarazel.de, bruce@momjian.us, robertmhaas@gmail.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_dump versus ancient server versions
In-Reply-To: <2314554.1638554971@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox