Re: multi-install PostgresNode fails with older postgres versions - Mailing list pgsql-hackers

On Mon, 19 Apr 2021 10:35:39 -0700
Mark Dilger <mark.dilger@enterprisedb.com> wrote:

> > On Apr 19, 2021, at 10:25 AM, Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
> > wrote:
> > 
> > On Mon, 19 Apr 2021 12:37:08 -0400
> > Andrew Dunstan <andrew@dunslane.net> wrote:
> >   
> >> 
> >> 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 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