On 4/19/21 10:43 AM, Mark Dilger wrote:
>
>> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan <andrew@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
olderservers, create data that cannot be created on newer servers (such as heap tuples with HEAP_MOVED_IN or
HEAP_MOVED_OFFbits set), upgrade, and test that new code handles the old data correctly. I think this is not only
usefulfor our test suites as a community, but is also useful for companies providing support services who need to
reproduceproblems 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.
I'll work on this. Meanwhile FTR here's my latest revision - it's a lot
less invasive of the main module, so it seems much more palatable to me,
and still passes my test down to 7.2.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
