Re: multi-install PostgresNode fails with older postgres versions

On Mon, 19 Apr 2021 10:35:39 -0700
Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:

> > 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.

Which means it could be OK to have a PostgresNode implementation, leaving in
core source-tree, which supports broader needs than the core ones (older
versions and some more methods)? Did I understood correctly?

If this is correct, I suppose this effort could be committed early in v15 cycle?

Does it deserve some effort to build some dedicated TAP tests for these
modules? I already have a small patch for this waiting on my disk for some more
tests and review...

Regards