I have searched the interwebs for PostgreSQL 10.4 (32 & 64) for Linux platforms and Windows platforms but have been unable to locate any binaries to download. All I can find is the 10.5 version (or 9.x). Any ideas on where to look?
Thanks!
As mentioned in Versioning policy,
the rightmost number denotes the minor release, so 10.5 is the most recent release of PostgreSQL 10:
Minor releases are numbered by increasing the last part of the
version number. Beginning with PostgreSQL 10, this is the second part
of the version number, e.g. 10.0 to 10.1; for older versions this is
the third part of the version number, e.g. 9.5.3 to 9.5.4
10.(x-1) is generally made unavailable as soon as 10.x is released, because 10.(x-1) is the same set of programs, but with known bugs not yet fixed: it should not be prefered over a more recent version.
In most cases, the will to install a specific outdated minor release is due to not knowing the version numbering policy.
Related
Postgresql website says "A dump/restore is not required for those running 14.X." (https://www.postgresql.org/docs/14/release-14-2.html#id-1.11.6.5.4)
Do I still need to use pg_upgrade or there is any other way to upgrade?
You only need to update the binaries using Ubuntu's package manager and restart Postgres (apt update then apt install postgresql-14)
pg_upgrade is only needed to upgrade between major versions (e.g. from 13 to 14 or from 14 to 15). Upgrading 14.1 to 14.2 is a minor version upgrade.
As per the docs:
Minor releases never change the internal storage format and are always compatible with earlier and later minor releases of the same major version number.
You are moving from 14.1 to 14.2 so this applies to your situation. That means you can just upgrade the binaries (so usually apt-get update && apt-get upgrade assuming you are using a repo with the latest release) and restart the service. However, it is worth reviewing the release notes particularly:
some bugs have been found that may have resulted in corrupted indexes, as explained in the first two changelog entries. If any of those cases apply to you, it's recommended to reindex possibly-affected indexes after updating.
PostgreSQL 10 is the new main version after 9.6. But if you look at postgresql.org you will find 10.1?
https://www.postgresql.org/about/news/1801/
Is 10.1 a new bugfix release for 10.0?
Can anyone explain that to me?
In version 10, the versioning method was changed. From the linked page:
Beginning with version 10, a major release is indicated by increasing
the first part of the version, e.g. 10 to 11. Before version 10, a
major release was indicated by increasing either the first or second
part of the version number, e.g. 9.5 to 9.6.
Thus 10 is the major version, 10.1 is the first point release of version 10. 10.2 is due out Feb 8th, 2018
I am seeing 2 versions (9.0.1 vs 8.2.1) of wildfly which were released on the same day. What is the difference between two versions and why there are 2 versions exist in parallel? I couldn't find it over the internet.
Wildfly ships on a very fast development cycle. Each major release 8.x, 9.x, 10.x contains major changes from the previous version. All current major work is being done on the 10.x beta versions.
The minor versions are for bugfixes related to that particular release. Since there are now people in production with both 8.x and 9.x, any critical bugs or security patches go into one of these releases. It is very possible a security issue could exist and be fixed in both 8.x.1 and 9.x.1.
JBoss EAP, which is based on WildFly, deliberately has a slower release schedule. For each major version they release they offer paid support for 4 years, so they change major versions much slower.
There is a good slide of the lifecycle of WildFly/JBoss on page 9 of this slide-deck from the RedHat Summit in June:
http://videos.cdn.redhat.com/summit2015/presentations/12186_red-hat-jboss-enterprise-application-platform-7-roadmap-new-features.pdf
Here is the official announcement for the pair of releases: -
http://wildfly.org/news/2015/07/23/WildFly-901-and-821/
I used pkg list entire command , and i got the output for version column as follows :
0.5.11-0.175.1.0.0.24.2.
How to find the SRU from this?
Can we upgrade/ downgrade to a particular SRU ?
SRU is an abbreviation for Support Repository Update, installing new package versions from the support repo for that OS, much like installing a patch cluster for older Solaris releases.
The various fields in the version is explained in Oracle Solaris Package Versioning.
Oracle only makes SRUs available to customers with support contracts - if you have a support contract you can read more about SRU's in the Oracle Support Knowledgebase at Solaris 11 Support Repositories Explained, and see what fixes are available in each SRU for Solaris 11.1 and Solaris 11.2.
If you run 'pkg info entire' it will show the SRU name in human readable format also (if you have installed from the support repo - otherwise it shows the Release info). The 4th digit in 0.175.1.0.0.24.2 is the SRU number
In the example above it is the base Solaris 11.1 release - no SRU has been installed yet.
If an SRU had been installed on top of that you'd get a version like 0.5.11-0.175.1.21.4.1 (aka Oracle Solaris 11.1 SRU21.4.1)
You can easily upgrade to an SRU but you can't downgrade unless you have an older Boot Environment (BE) from which to upgrade to the SRU you want.
JProfiler agent seems to require glibc 2.7, but Centos has glibc 2.5. Has anyone successfully compiled the jprofiler agent for glibc 2.5 or did previous version of JProfiler create agents with 2.5?
Actul error is
Error occurred during initialization of VM
Could not find agent library /opt/jprofiler/bin/linux-x64/libjprofilerti.so in absolute path, with error: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by /opt/jprofiler/bin/linux-x64/libjprofilerti.so)
The problem is that JProfiler you are using has been built on a system with glibc-2.7 (or later).
In general, UNIX systems support backwards compatibility (code compiled on an older system continues to work on a newer one), but not forward compatibility (you can't expect code built on a newer system to work on an older one).
Your choices are: upgrade your version of glibc, or obtain a different build of JProfiler (that was built on glibc-2.5 based system or older).
That's actually a regression in 7.0.1, an easy workaround is to use 7.0:
http://download.ej-technologies.com/jprofiler/jprofiler_linux_7_0.tar.gz
We'll fix this dependency problem shortly (my company develops JProfiler). Thanks for letting us know.