[protomyth]

[not gp post, but this is a normal situation]

Because some folks need to go through a long, drawn out process to upgrade internal software and might already have some place in the pipeline to put the upgrade so it will get tested with everything else.

If its a security issue for your current installation, you go now and hope, but if it can wait for a release then you do that.

[DrJokepu]

It seems to me that even large, overly bureaucratic corporations need a process in place that allows deploying critical security updates in a reasonably expedient manner. Is this uncommon?

[mkopinsky]

Well, it's only a critical security update if it affects your installation. If there's a way to protect without a quick rush software upgrade, you may as well wait until the next scheduled software upgrade.

[vidarh]

Exactly. We were prepared for a "quick rush" but when the details were released we did a combination of nmap to look for any accidentally exposed Postgres installs + adding explicit firewall rules to reject all traffic on the related ports (all of them should be rejected by default rules anyway, but we wanted to ensure none of the ports had been accidentally opened up) "just in case", and at that point we felt we could take a slower, more measured roll out of the upgrade. In 5 minutes we were "in the clear" and could breathe a sigh of relief.

It's still important to apply the udates, as I wrote elsewhere, because it's one more way someone can mess you up badly if they have managed to penetrate other parts of our systems, but upgrades no matter how seemingly safe can also cause problems (fore example I test upgraded one VM that refused to come back up again afterwards - not Postgres' fault, but a config change someone had clearly not tested properly).

But in this case, knowing we have blocked the main attack vector means we can take the time to take a copy of each database VM we run, test apply the upgrade and verify everything works correctly before applying it live, instead of rushing it out.