Raise PG min version to 9.6

[albertlast]

Same reason like the pr 2 years before: #4788
good thing on this,
we got now always ignore support on pg side and didn't had to check any more.

[albertlast]

Should be merged asap and not first to final version.

[jdarwood007]

https://www.postgresql.org/download/linux/redhat/
https://www.postgresql.org/download/linux/debian/
https://www.postgresql.org/download/linux/ubuntu/

https://wiki.centos.org/About/Product
https://forums.cpanel.net/threads/upgrade-postgresql-version.643725/

Based on this information, I would say 9.5 or 9.6 doesn't mater it seems. If I see all the supported distributions right. cPanel seems to follow mostly the distro releases so Centos 7/8 should be the current ones.

The judging of supporting this is the Distros support and postgres support itself.

[tinoest]

You do realise the default pgsql version on CentOS is 9.2.24 and that is supported until 2024

[albertlast]

yea postgres 9.2.24 is eol and centos repo for newer version exists.
https://www.postgresql.org/download/linux/redhat/

[tinoest]

yea postgres 9.2.24 is eol and centos repo for newer version exists.
https://www.postgresql.org/download/linux/redhat/

It’s still supported by RedHat for security fixes.

[albertlast]

yea than ask redhat to support smf.
pg is small niche of smf setup, it make no sense to spend to mutch support on broad band version support.

[tinoest]

The change you’re proposing isn’t exactly significant to maintain support for 9.4 at the least. Does bumping to 9.6 really give you that many advantages?

[albertlast]

Give it you any advantages to stay on a old postgres version?

Smf can drop many code lines and provide a better user experience,
since we need less workarounds for old versions.
for example
#6170 or #6171

[tinoest]

I don’t see anything significant in those PR’s, you might as well increase the version of MySQL to 5.6 whilst you’re at it. Drop the MySQL workarounds. As that’s also EOL

[MissAllSunday]

MySQL is a bit more difficult to raise since nearly 95% or so of the SMF installs are on MySQL (or its relatives) PG is a lot more easier due to the small amount of installs.

But yes, I've been thinking about raising MySQL to 5.6 as well, just need to gather more data (SMF.org) on it to make a solid decision.

[albertlast]

we had to think als in smf2.1 live time,
since ever year a new version came out of pg,
so we need to start as focus as can, since of the time of 2.1 existing many new version of pg get released.

Since centos in his form is dead and centos stream got newer version of pg,
it make no sense to look far back to support things which exists now,
when 2.1 is living in the future.

[tinoest]

I’ll repeat CentOS 7 is supported until 2024. CentOS 8 is switching to stream this year, I don’t necessarily disagree with you, just you have to treat both architectures the same.

[albertlast]

Linux got more 100 distro,
so i treat them equal by not looking at one for this decision,
It's more important to look at the company/organization (postgresql.org) how provide the software ther decision,
since it's porovide the repo for the distros and support for issues.

[tinoest]

You and I both know that CentOS/RedHat and Ubuntu/Debian are the big players in the server market with over 80% of the market share. SuSe, Arch, Slack and Gentoo are the others.

So taking 16.04 LTS which is also supported until 2024 that’s version 9.5. Debian Stretch EOL 2022 is version 9.6.

SuSe I don’t know enough about. The other’s to my knowledge don’t have an LTS

Please if you’re going to state things check to make sure they’re correct.

[albertlast]

Like i said befor i don't like it, that you handle the linux not equal,
by focusing on the some distro and ther >own< repo and own decisions,
the company how provide pg is postgresql ther repo and software deliver count to all not the special behavior between every own distro.

When you want to use pg <9.5 than stay on smf 2.0 untile 2024 no one is forcing you or switch to mysql.
Better idea would be to use the offical pg repo.

You want to force smf to support software which got released 9-7 years ago,
when smf 2.1 get released (possible in 2022) smf 2.1 stay for 6 years or more.
So on of the this live span 9.2 got 16 years old.

[tinoest]

By your own argument the support for less than php 7.3 should also occur.

We’re going round in circles, I don’t see what harm it does keeping support for 9.4 when the only change is the CTE and ALTER TABLE support.

It’s not like SMF2.0 has kept support with what it had at the start. The PHP version for one has increased. I’m pretty sure the MySQL also has.

[albertlast]

Sure php should be this high,
i guess i mention many time that this i my opinion.

I also see no harm, that someone how want to use pg below 9.6 use smf 2.0.x,
since it make sense because they also got a php version from this time.

When you want to use modern software,
than provide a modern env = software how is supported by the company how build it.

[jdarwood007]

CentOS 7 supports 9.2, but there are repos that support newer versions of postgresql.
However reading this: https://features.cpanel.net/topic/improved-postgresql-support
cPanel itself seems to use the distro version. So to modify my previous response, I don't think we can do 9.5/9.6 safely without accepting that it may cost some support for people on supported OSes/distros.

@albertlast Is there anything we intend to merge that is only supported in 9.2 or higher? If so, can backwards compatible functions be used to provide legacy support for them to bridge the gap? Even if they come at a performance cost, that can be acceptable because its maintaining a backwards compatibility for older versions.

[albertlast]

Since the user/admin got options:

• to stay on 2.0.x when they want to use smf with pg below 9.6 or
• decide to use smf 2.1 with mysql when they want to run smf 2.1 on centos or other distro where pg is not available in the right version

since the usergroup is low, how use pg, the effort needs to be reasonable in supported version range of pg.

So i see no reason to hold back this pr.

[jdarwood007]

@MissAllSunday and @live627,

Can you provide feedback? This normally wouldn't be a PR to worry about merging for RC4. But there are at least 2 related PRs that depend on this and they change how things like the upgrader functions. If this will merge, it should merge in time for RC4 to ensure any bugs can be fixed up for final.

[MissAllSunday]

Which related PRs?

I saw: #6170 which introduces new sintax that could possible further divide the differences between mysql and PG behaviour, something we shouldn't let happen.

I am OK with raising the min version only if it doesn't require us to make changes to what we currently have, that is, to have full backwards compatibility, if raising the version requires us to make modifications then no, we shouldn't raise it at this point.

[albertlast]

#6170 introduce pg syntax to match the mysql behavior,
nothing else.

[jdarwood007]

#6255 changes the upgrader logic for Postgresql 9.6+
#6171 also is for PG 9.6+
@albertlast Correct me if I'm wrong, but #6323 also is for PG 9.6+?

[albertlast]

i see no notes in the pr so i guess not,
but not 100% sure since i focused my pr for pg 9.6+ and not any more below.

[sbulen]

@albertlast - everything in this PR is also in #6171 . Should we close this out & keep #6171?