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@momjian.us> 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?"
