Re: pg_dump versus ancient server versions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, 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 17:10:07
Message-ID: 2310708.1638551407@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2021-12-03 17:15:28 Re: extended stats on partitioned tables
Previous Message Andrei Zubkov 2021-12-03 16:55:53 Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements