We just lately recognized {that a} batch of our Percona Server for PostgreSQL RPM packages have been inadvertently compiled with the debug assertion flag (–enable-cassert) enabled.
Whereas these assertions are invaluable for our builders in the course of the testing part, they aren’t supposed for manufacturing use. We’ve since rebuilt the packages and strongly advocate that all customers of the affected variations replace to the newest model instantly.
Why Assertions Don’t Belong in Manufacturing
An “assertion” is a sanity test embedded within the code. It says: “The developer assumes that at this actual level, Situation X have to be true. If it isn’t, one thing is basically improper.“
Whenever you allow these in a manufacturing setting, a number of crucial points come up:
1. Extreme Efficiency Degradation
PostgreSQL performs hundreds of thousands of operations per second. With assertions enabled, the CPU should consistently cease and confirm the inner state of the database.
- The Consequence: You’ll possible expertise a major enhance in CPU utilization and a corresponding lower in transaction throughput. In lots of instances, efficiency can degrade by 20% to 50% relying on the workload.
2. The “Fail-Quick” Downside (Sudden Downtime)
In a regular manufacturing construct, if a non-critical inconsistency happens, PostgreSQL would possibly log a warning or try to get better gracefully.
- The Consequence: With assertions enabled, the instruction is to abort instantly. If an assertion fails, the whole backend course of crashes as rapidly as potential, so the coredump/debugger is as near the originating difficulty as potential. Whereas that is useful for catching bugs in a lab, it might probably result in potential service restarts, dropped connections, and traditionally false positives in a reside setting.
3. Elevated Binary Measurement and Reminiscence Overhead
The inclusion of debug symbols and assertion logic will increase the footprint of the PostgreSQL binaries. This could result in much less environment friendly use of instruction caches and barely greater reminiscence consumption per course of.
What Occurred?
Throughout an replace to our construct pipeline, a configuration flag used for inside testing was incorrectly utilized to the manufacturing RPM construct scripts. This brought about the compiler to incorporate code paths which are usually stripped out for efficiency and stability.
Really useful Motion:
- Verify your model: In case you put in or up to date inside the final 4 months, you might be possible affected.
- Affected variations:
- 18.1
- 17.6 & 17.7
- 16.10 & 16.11
- 15.14 & 15.15
- 14.19 & 14.20
- 13.22 & 13.23
- Guide test: “pg_config –configure”
- In case you see “–enable-cassert” within the output, you’re affected!
- Affected variations:
- Replace instantly to the most recent launched RPMs or photographs.
The package deal numbers have modified as a part of the rebuild, not the PostgreSQL variations. Please double-check pg_config to make sure you’re not affected.
We apologize for this oversight and are implementing further automated checks in our CI/CD pipeline to stop debug flags from reaching our manufacturing repositories sooner or later. When you have any questions or require additional help, please don’t hesitate to contact us.
Newest mounted main releases:
https://docs.percona.com/postgresql/18/release-notes/release-notes-v18.1.1.html
https://docs.percona.com/postgresql/17/release-notes/release-notes-v17.7.1.html
https://docs.percona.com/postgresql/16/release-notes/release-notes-v16.11.html
https://docs.percona.com/postgresql/15/release-notes-v15.15.html
https://docs.percona.com/postgresql/14/release-notes/release-notes-v14.20.html
https://docs.percona.com/postgresql/13/release-notes/release-notes-v13.23.html
