> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan <and...@dunslane.net> wrote:
>
> I think therefore I'm inclined for now to do nothing for old version
> compatibility.
I agree with waiting until the v15 development cycle.
> I would commit the fix for the IPC::Run caching glitch,
> and version detection
Thank you.
> I would add a warning if the module is used with
> a version <= 11.
Sounds fine for now.
> The original goal of these changes was to allow testing of combinations
> of different builds with openssl and nss, which doesn't involve old
> version compatibility.
Hmm. I think different folks had different goals. My personal interest is to
write automated tests which spin up older servers, create data that cannot be
created on newer servers (such as heap tuples with HEAP_MOVED_IN or
HEAP_MOVED_OFF bits set), upgrade, and test that new code handles the old data
correctly. I think this is not only useful for our test suites as a community,
but is also useful for companies providing support services who need to
reproduce problems that customers are having on clusters that have been
pg_upgraded across large numbers of postgres versions.
> As far as I know, without any compatibility changes the module is fully
> compatible with releases 13 and 12, and with releases 11 and 10 so long
> as you don't want a standby, and with releases 9.6 and 9.5 if you also
> don't want a backup. That makes it suitable for a lot of testing without
> any attempt at version compatibility.
>
> We can revisit compatibility further in the next release.
Sounds good.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
