Thread: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10

On 11/20/24 22:44, 김주연 wrote:
> Hello, I am currently using PostgreSQL 11.10 and would like to know if 
> the CVE-2024-10979 vulnerability affects this version.

Postgres 11 is past EOL, see:

https://www.postgresql.org/support/versioning/


> If it does impact my version, I would like to know which version I 
> should upgrade to.

Any version from 13+.

-- 
Adrian Klaver
adrian.klaver@aklaver.com

Thank you for your response regarding the affected versions of PostgreSQL. I have a follow-up question for clarification:

The PostgreSQL documentation mentions that the versions with a fix for CVE-2024-10979 are 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21. However, your reply states that any version greater than 13+ should suffice.

Could you please confirm if upgrading to one of the specific versions listed above is mandatory, or is it acceptable to upgrade to any version higher than 13

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thursday, November 21, 2024, Subhash Udata <subhashudata@gmail.com>
> wrote:
>> The PostgreSQL documentation mentions that the versions with a fix for
>> CVE-2024-10979 are *17.1, 16.5, 15.9, 14.14, 13.17, and 12.21*. However,
>> your reply states that any version greater than 13+ should suffice.
>> Could you please confirm if upgrading to one of the specific versions
>> listed above is mandatory, or is it acceptable to upgrade to any version
>> higher than 13

Minor versions earlier than those do not contain the fix.

> The fact you are on version 11 means you should not expect an answer to the
> question whether this newly discovered CVE affects you - that would be
> expecting support for a long-unsupported version.

The Postgres security team does not ordinarily test out-of-support
branches, so no official answer to that will be forthcoming.
Unofficially, however, I have no doubt that this bug is quite ancient.

            regards, tom lane

On 11/21/24 19:57, Subhash Udata wrote:
> Hi Adrian,
> 
> Thank you for your response regarding the affected versions of 
> PostgreSQL. I have a follow-up question for clarification:
> 
> The PostgreSQL documentation mentions that the versions with a fix for 
> CVE-2024-10979 are *17.1, 16.5, 15.9, 14.14, 13.17, and 12.21*. However, 
> your reply states that any version greater than 13+ should suffice.

Any major version 13+. Postgres uses a X.x numbering scheme where X is 
major version and x is minor version. If you go here:

https://www.postgresql.org/support/versioning/

you will see that translates to in terms of support. If you move to 13.x 
you will have one more year before you would need to move to a newer 
version. It is up to you to decide if that is okay or whether you want 
to move a version that is newer to have more time to plan the next move. 
In either case you should use the latest minor release that is current 
at the time. Minor releases are bug/security fixes and it is important 
that you keep up with them. The latest round of minor releases where 
done yesterday and that is what you should be installing.


> 
> Could you please confirm if upgrading to one of the specific versions 
> listed above is mandatory, or is it acceptable to upgrade to any version 
> higher than 13?
> 
> Your guidance will help us determine the appropriate upgrade path for 
> our environment.
> 
> Thank you for your time and assistance.
> 
> 
> On Thu, 21 Nov 2024 at 12:24, Adrian Klaver <adrian.klaver@aklaver.com 
> <mailto:adrian.klaver@aklaver.com>> wrote:
> 
>     On 11/20/24 22:44, 김주연 wrote:
>      > Hello, I am currently using PostgreSQL 11.10 and would like to
>     know if
>      > the CVE-2024-10979 vulnerability affects this version.
> 
>     Postgres 11 is past EOL, see:
> 
>     https://www.postgresql.org/support/versioning/
>     <https://www.postgresql.org/support/versioning/>
> 
> 
>      > If it does impact my version, I would like to know which version I
>      > should upgrade to.
> 
>     Any version from 13+.
> 
>     -- 
>     Adrian Klaver
>     adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> 
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com

On 11/21/24 20:31, Subhash Udata wrote:
> Thank you for your detailed response. I would like to clarify my 
> situation further to ensure I take the appropriate steps.
> 
> 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.

Whoa, I thought the topic of discussion from your first post and the 
email subject was:

"I am currently using PostgreSQL 11.10 and would like to know if the
CVE-2024-10979 vulnerability affects this version."

> 
> 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.

The upgrades fixed more then this issue, so yes you should upgrade for 
all the reasons listed in the release notes for 15.1 to 15.10.

> 
> Thank you for your time and support.
> 
> 
> On Fri, 22 Nov 2024 at 09:39, David G. Johnston 
> <david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>> wrote:
> 
>     On Thursday, November 21, 2024, Subhash Udata
>     <subhashudata@gmail.com <mailto:subhashudata@gmail.com>> wrote:
> 
> 
>         Thank you for your response regarding the affected versions of
>         PostgreSQL. I have a follow-up question for clarification:
> 
>         The PostgreSQL documentation mentions that the versions with a
>         fix for CVE-2024-10979 are *17.1, 16.5, 15.9, 14.14, 13.17, and
>         12.21*. However, your reply states that any version greater than
>         13+ should suffice.
> 
>         Could you please confirm if upgrading to one of the specific
>         versions listed above is mandatory, or is it acceptable to
>         upgrade to any version higher than 13
> 
> 
>     It was literally just reported and fixed.  If you are on a supported
>     release of PostgreSQL you have the fix.  If you are not, you don’t.
> 
>     At this point only major versions 13+ are supported.
> 
>     Upgrading to an unsupported minor release is never recommended.
> 
>     The fact you are on version 11 means you should not expect an answer
>     to the question whether this newly discovered CVE affects you - that
>     would be expecting support for a long-unsupported version.
> 
>     Which of the 5 currently supported releases you should upgrade to is
>     a decision you need to make given your circumstances.
> 
>     David J.
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com

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

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.

Yours,
Laurenz Albe

On 11/21/24 20:31, Subhash Udata wrote:

Thank you for your detailed response. I would like to clarify my situation further to ensure I take the appropriate steps.

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.

Whoa, I thought the topic of discussion from your first post and the email subject was:

"I am currently using PostgreSQL 11.10 and would like to know if the
CVE-2024-10979 vulnerability affects this version."

On 11/21/24 20:53, David G. Johnston wrote:
> On Thursday, November 21, 2024, Adrian Klaver <adrian.klaver@aklaver.com 
> <mailto:adrian.klaver@aklaver.com>> wrote:
> 
>     On 11/21/24 20:31, Subhash Udata wrote:
> 
>         Thank you for your detailed response. I would like to clarify my
>         situation further to ensure I take the appropriate steps.
> 
>         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.
> 
> 
>     Whoa, I thought the topic of discussion from your first post and the
>     email subject was:
> 
>     "I am currently using PostgreSQL 11.10 and would like to know if the
>     CVE-2024-10979 vulnerability affects this version."
> 
> 
> No, I just think Subhash hijacked this thread.  At least the email 
> address of the OP is a different one.

Oops missed that, now it makes sense.

> 
> David J.
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com

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:

under development: V7.3-SP1 (we will not support 15.9 as cluster in SP1)
    used ESQL/C 15.9 (i.e. PostgreSQL client side)
    migrate the used cluster/database 'from' --> 'to'
    15.1  --> 16.5
    16.2  --> 16.5

released: V7.3 (we will not support 15.9 as cluster in V7.3)
    used ESQL/C 15.1 (i.e. PostgreSQL client side)
    migrate the used cluster/database 'from' --> 'to'
    15.1  --> 16.5
    16.2  --> 16.5

released: V7.2 (we will not support 15.9 as cluster in V7.2)
    used ESQL/C 11.4 (i.e. PostgreSQL client side)
    migrate the used cluster/database 'from' --> 'to'
    13.1  --> 16.5
    16.2  --> 16.5

Especially the version V7.2 (released in 2021) can't be updated on the
client side, the cluster will be migrated to 16.5. I assume that 
CVE-2024-10979 affects the server side, and not the client side.

Any further comments on this?

Thanks

    matthias

-- 
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

On 11/22/24 10:00, 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:
>
> under development: V7.3-SP1 (we will not support 15.9 as cluster in SP1)
>      used ESQL/C 15.9 (i.e. PostgreSQL client side)
>      migrate the used cluster/database 'from' --> 'to'
>      15.1  --> 16.5
>      16.2  --> 16.5
>
> released: V7.3 (we will not support 15.9 as cluster in V7.3)
>      used ESQL/C 15.1 (i.e. PostgreSQL client side)
>      migrate the used cluster/database 'from' --> 'to'
>      15.1  --> 16.5
>      16.2  --> 16.5
>
> released: V7.2 (we will not support 15.9 as cluster in V7.2)
>      used ESQL/C 11.4 (i.e. PostgreSQL client side)
>      migrate the used cluster/database 'from' --> 'to'
>      13.1  --> 16.5
>      16.2  --> 16.5

Why not decouple client libs from the server ? i.e. psql works great 
with many versions greater than its own. And certainly with same major 
versions. You could retain the same client libs and just upgrade the 
PgSQL server to the highest minor version of the major version that you 
support.

Granted, I am coming from JDBC/psql land but still those restrictions 
above just seem too much.

Of course SQL correctness from version to version (such as "trailing 
junk", standard_conforming_strings, etc ..) and performance are tasks 
that has to be done, you can't skip those. But IMHO the server version 
in the general case is independent or should be independent from the 
app. We recently migrated from 10.23 -> 16.4 with slight bruises (almost 
6+ months preparation by me and 3-4 months preparation from the dept team).

Just my 5 cents.

>
> Especially the version V7.2 (released in 2021) can't be updated on the
> client side, the cluster will be migrated to 16.5. I assume that
> CVE-2024-10979 affects the server side, and not the client side.
>
> Any further comments on this?
>
> Thanks
>
>     matthias
>

El día viernes, noviembre 22, 2024 a las 11:01:29 +0200, Achilleas Mantzios - cloud escribió:

> > under development: V7.3-SP1 (we will not support 15.9 as cluster in SP1)
> >      used ESQL/C 15.9 (i.e. PostgreSQL client side)
> >      migrate the used cluster/database 'from' --> 'to'
> >      15.1  --> 16.5
> >      16.2  --> 16.5
> > 
> > released: V7.3 (we will not support 15.9 as cluster in V7.3)
> >      used ESQL/C 15.1 (i.e. PostgreSQL client side)
> >      migrate the used cluster/database 'from' --> 'to'
> >      15.1  --> 16.5
> >      16.2  --> 16.5
> > 
> > released: V7.2 (we will not support 15.9 as cluster in V7.2)
> >      used ESQL/C 11.4 (i.e. PostgreSQL client side)
> >      migrate the used cluster/database 'from' --> 'to'
> >      13.1  --> 16.5
> >      16.2  --> 16.5
> 
> Why not decouple client libs from the server ? i.e. psql works great with
> many versions greater than its own. And certainly with same major versions.
> You could retain the same client libs and just upgrade the PgSQL server to
> the highest minor version of the major version that you support.
> ...

This is exactly the plan. For all the three versions the cluster will be
migrated to 16.5 and the client side will stay for the released version
with what they currently use (11.4 or 15.1). And for the version under
development 15.9

    matthias

-- 
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023)

I, Matthias, I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Especially the version V7.2 (released in 2021) can't be updated on the
client side, the cluster will be migrated to 16.5. I assume that
CVE-2024-10979 affects the server side, and not the client side.

On Fri, 2024-11-22 at 09:00 +0100, Matthias Apitz wrote:
> > > 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.
>
> 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.

And you didn't plan how you intend to ship software updates to these
customers?

> "You should *always* update ..." is nice to say, but in the described land
> not easy to do.

If you say so.  Still, that is a problem that will come to bite you
some day, as soon as your customers hit some PostgreSQL bug.

> I assume that
> CVE-2024-10979 affects the server side, and not the client side.

Right.  I wonder why you are so keen on that vulnerability and ignore
all the others discovered since 15.0.

> Any further comments on this?

No.  I told you that you should update, and you explained in great
detail why you cannot.  There is nothing more to say.  Good luck.

Yours,
Laurenz Albe

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?"

On Sat, Nov 23, 2024 at 01:30:13PM -0500, Greg Sabino Mullane wrote:
> On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian <bruce@momjian.us> wrote:
> 
>     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?
> 
> 
> Hmm I'm not sure what else we can say. Our upgrade process is already
> drop-dead-simple, especially compared to many (most?) other products out there.
> People painting themselves into corners is not something we can really help
> with.

I am wondering if we can highlight which upgrades are most important for
users who have complex upgrade processes.  Maybe CVEs and corruption
fixes?

-- 
  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?"

On 11/23/24 10:57, Bruce Momjian wrote:
> On Sat, Nov 23, 2024 at 01:30:13PM -0500, Greg Sabino Mullane wrote:
>> On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian <bruce@momjian.us> wrote:
>>
>>      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?
>>
>>
>> Hmm I'm not sure what else we can say. Our upgrade process is already
>> drop-dead-simple, especially compared to many (most?) other products out there.
>> People painting themselves into corners is not something we can really help
>> with.
> 
> I am wondering if we can highlight which upgrades are most important for
> users who have complex upgrade processes.  Maybe CVEs and corruption
> fixes?

Personally I would point then at:

https://www.postgresql.org/list/pgsql-announce/

and/or:

https://www.postgresql.org/docs/release/

I would think that informs users and let's them determine what is 
important to their situation.



-- 
Adrian Klaver
adrian.klaver@aklaver.com

 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?"