Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
От | Bruce Momjian |
---|---|
Тема | Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10 |
Дата | |
Msg-id | Z0JLe8KsJy_6Si6O@momjian.us обсуждение исходный текст |
Ответ на | Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10 (Ron Johnson <ronljohnsonjr@gmail.com>) |
Ответы |
Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
|
Список | pgsql-general |
On Sat, Nov 23, 2024 at 03:24:47PM -0500, Ron Johnson wrote: > On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian <bruce@momjian.us> wrote: > [snip] > > 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? > > > What guidance is needed? Even for us, where firewalls block our servers from > https://download.postgresql.org, it's as simple as downloading the relevant RPM > files once (and that done with a PowerShell script), then patching thusly: > > WinScp PG16.4_RHEL8 dir to each server, and on each server > $ sudo -iu postgres pg_ctl stop -mfast -wt9999 -D /path/to/data > $ sudo yum install PG16.4_RHEL8/*rpm > $ sudo -iu postgres pg_ctl start -wt9999 -D /path/to/data > > Those three sudo commands take, at most, three minutes. I am thinking more of cases where you have 100+ customers, and you need to coordinate/connect to each company to perform the upgrade. Doing that every quarter might be a lot of work, and it might be hard to justify for every minor release. -- 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?"
В списке pgsql-general по дате отправления: