On Fri, Nov 22, 2024 at 09:00:18AM +0100, Matthias Apitz wrote: > El día viernes, noviembre 22, 2024 a las 05:52:34 +0100, Laurenz Albe escribió: > > > On Fri, 2024-11-22 at 10:01 +0530, Subhash Udata wrote: > > > Currently, my environment is running PostgreSQL 15.0. I understand that version > > > 15.9 contains the fix for CVE-2024-10979, as mentioned in the release notes. > > > Given that I am not using the PL/Perl extension in my environment, I wanted to ask: > > > * Is it still mandatory to upgrade specifically to version 15.9, or would > > > remaining on version 15.0 suffice in this case? > > > I appreciate your guidance on whether this upgrade is necessary, considering the > > > specifics of my setup. > > > > If you don't use PL/Perl, you are not affected by that security vulnerability. > > > > I wonder what you mean by "mandatory". > > > > We won't fine or punish you if you don't update PostgreSQL, but perhaps it > > would make your employer unhappy. If you stay on 15.0, you will be subject to > > thirteen other security vulnerabilities (if I counted right), and you may end > > up with corrupted GIN and BRIN indexes. Additionally, you will be subject to > > countless known bugs that have been fixed since. > > > > You should *always* update to the latest minor release shortly after it is > > released. Everything else is negligent. > > Laurenz, et all, > > The company I'm working for is producer of a Library Management System > with C/C++ written servers on Linux, using ESQL/C and DBI interfaces of > PostgreSQL (and older version Sybase too) and the software is deployed > to 100++ customer installations, sometimes with limited own IT know how. > > "You should *always* update ..." is nice to say, but in the described land > not easy to do. For the two released versions of our software (V7.2 and > V7.3) and the current version in development (V7.3-SP1) we plan the > following migrations of the server and client side of PostgreSQL: I have to admit, for this question, we just point people to: https://www.postgresql.org/support/versioning/ and say bounce the database server and install the binaries. What I have never considered before, and I should have, is the complexity of doing this for many remote servers. Can we improve our guidance for these cases? -- Bruce Momjian <bruce@xxxxxxxxxx> https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"
