Re: pg_dump versus ancient server versions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump versus ancient server versions
Date: 2021-12-03 18:09:31
Message-ID: 2314554.1638554971@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2021-12-03 18:20:44 Re: O(n) tasks cause lengthy startups and checkpoints
Previous Message Bossart, Nathan 2021-12-03 17:55:04 Re: should we document an example to set multiple libraries in shared_preload_libraries?