Re: multi-install PostgresNode fails with older postgres versions

> On Apr 19, 2021, at 10:25 AM, Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> wrote:
>
> On Mon, 19 Apr 2021 12:37:08 -0400
> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>>
>> On 4/19/21 10:43 AM, Mark Dilger wrote:
>>>
>>>> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan <andrew(at)dunslane(dot)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.
>>
>>
>> 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.
>
> I spend a fair bit of time to wonder how useful it could be to either maintain
> such a module in core, including for external needs, or creating a separate
> external project with a different release/distribution/packaging policy.
>
> Wherever the module is maintained, the goal would be to address broader
> needs, eg. adding a switch_wal() method or wait_for_archive(), supporting
> replication, backups, etc for multi-old-deprecated-PostgreSQL versions.
>
> To be honest I have mixed feelings. I feel this burden shouldn't be carried
> by the core, which has restricted needs compared to external projects. In the
> opposite, maintaining an external project which shares 90% of the code seems to
> be a useless duplicate and backport effort. Moreover Craig Ringer already opened
> the door for external use of PostgresNode with his effort to install/package it,
> see:
> https://www.postgresql.org/message-id/CAGRY4nxxKSFJEgVAv5YAk%3DbqULtFmNw7gEJef0CCgzpNy6O%3D-w%40mail.gmail.com
>
> Thoughts?

The community needs a single shared PostgresNode implementation that can be used by scripts which reproduce bugs. For bugs that can only be triggered by cross version upgrades, the scripts need a PostgresNode implementation which can work across versions. Likewise for bugs that can only be triggered when client applications connect to servers of a different version.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company