Horton

Re: multi-install PostgresNode fails with older postgres versions

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>, Mark Dilger <mark.dilger@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-04-07T19:09:24Z
Lists: pgsql-hackers 
On 2021-Apr-07, Andrew Dunstan wrote:

> Aren't you likely to end up duplicating substantial amounts of code,
> though?

No — did you look at his code?  Each version is child of the one just
above, so you only need to override things where behavior changes from
one version to the next.

> I'm certainly not at the stage where I think the version-aware
> code is creating too much clutter. The "forest of conditionals" seems
> more like a small thicket.

After comparing both approaches, I think ioguix's is superior in
cleanliness.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
<Schwern> It does it in a really, really complicated way
<crab> why does it need to be complicated?
<Schwern> Because it's MakeMaker.

Commits

  1. Teach PostgresVersion all the ways to mark non-release code

  2. Make PostgresNode version aware

  3. Avoid unfortunate IPC::Run path caching in PostgresNode

  4. Change pg_ctl to detect server-ready by watching status in postmaster.pid.