Software-update: PostgreSQL 12.18 / 13.14 / 14.11 / 15.6 / 16.2

Er zijn updates verschenen voor alle nog ondersteunde versies van PostgreSQL. Dit populaire 'opensource relational database management system' draait op een groot aantal besturingssystemen en is daardoor uitstekend inzetbaar in diverse omgevingen. Het is een afgeleide van Ingres, nadat de hoofdontwikkelaar daarvan voor zichzelf is begonnen en deze database van opensource closedsource werd. De releasenotes voor deze uitgave kunnen hieronder worden gevonden.

PostgreSQL 16.2, 15.6, 14.11, 13.14, and 12.18 Released!

The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 16.2, 15.6, 14.11, 13.14, and 12.18. This release fixes one security vulnerability and over 65 bugs reported over the last several months. If you use GIN indexes, you may need to reindex after updating to this release. Please see the release notes for more information. For the full list of changes, please review the release notes.

Security Issues CVE-2024-0985: PostgreSQL non-owner REFRESH MATERIALIZED VIEW CONCURRENTLY executes arbitrary SQL.CVSS v3 Base Score: 8.0.Supported, Vulnerable Versions: 12 - 15.

One step of a concurrent refresh command was run under weak security restrictions. If a materialized view's owner could persuade a superuser or other high-privileged user to perform a concurrent refresh on that view, the view's owner could control code executed with the privileges of the user running REFRESH. The fix for the vulnerability makes is so that all user-determined code is run as the view's owner, as expected.

Bug Fixes and Improvements

This update fixes over 65 bugs that were reported in the last several months. The issues listed below affect PostgreSQL 16. Some of these issues may also affect other supported versions of PostgreSQL.

• Fix memory leak when performing JIT inlining that could lead to out-of-memory conditions.
• Several query planner fixes.
• Align MERGE behavior with UPDATE when updating a partition key column and skip firing AFTER UPDATE ROW trigger and other post-update actions.
• Fix problems with duplicate token names in ALTER TEXT SEARCH CONFIGURATION ... MAPPING commands.
• Fix DROP ROLE with duplicate role names.
• Properly lock the associated table during DROP STATISTICS to prevent errors if ANALYZE is running concurrently.
• Fix function volatility checking for GENERATED and DEFAULT expressions.
• Ensure collation matches when matching an existing index to a new partitioned index.
• Avoid failure if a child index is dropped concurrently with REINDEX INDEX on a partitioned index.
• Fix for locking during cleanup of GIN indexes. For this case, if multiple processes tried to clean the same GIN index page, there was a chance of index corruption. If you believe you were affected by this issue, reindex your GIN indexes after installing this update.
• Avoid failure with partitioned SP-GiST indexes.
• Several ownership fixes for large objects.
• In EXPLAIN (BUFFERS), change name of I/O timing data "shared/local" to "shared".
• Ensure durability of the CREATE DATABASE command if a system crash occurred during or shortly after execution.
• Add more logging messages when starting and ending recovery from a backup.
• Revert a change that made the walreceiver process unresponsive to SIGTERM while waiting for a replication connection to be established.
• Several fixes for logical replication.
• Fix incompatibility with OpenSSL 3.2.
• Fix PL/pgSQL to allow CREATE FUNCTION/CREATE PROCEDURE SQL commands that use SQL-standard function bodies.
• Fix for error handling in libpq pipeline mode.
• Ensure initdb always uncomments postgresql.conf entries for the lc_ family of parameters.
• In pg_dump, don't dump RLS policies or security labels for extension member objects.

This release also updates time zone data files to tzdata release 2024a for DST law changes in Greenland, Kazakhstan, and Palestine, plus corrections for the Antarctic stations Casey and Vostok. Also historical corrections for Vietnam, Toronto, and Miquelon.

Versienummer	12.18 / 13.14 / 14.11 / 15.6 /
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Solaris, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website	PostgreSQL
Download	https://www.postgresql.org/download/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (15)

[Master FX]

Blijf het bijzonder vinden; waarom worden er zoveel versie blijvend gesupport? Is het zo slecht migreren tussen verschillende versies van deze database?

[Mattashii]

Omdat nieuwe features vaak nieuwe bugs introduceren maken veel productietaken vaak pas gebruik van de 2e of 3e bugfix-release van elke release. Ook zijn niet alle niewe features altijd een verbetering voor iedere gebruiker, dus kiezen veel mensen er voor om even geduld te hebben met het updaten van hun database. Hierdoor zijn er veel productiedatabases die pas een half jaar (of later) na een major release beginnen met het upgradeproces.

Daarnaast is een PostgreSQL cluster niet verschrikkelijk vlug te upgraden naar een nieuwe major release, omdat vrijwel altijd het formaat van de database-metadata aangepast is tussen verschillende major releases. Dat betekent dat het upgrade-proces effectief de hele database-definitie dumpt en een nieuwe definitie opzet; en dat kan vrij veel tijd kosten als je heel veel tabellen of databases hebt. Gedurende dit proces is de database ook nog eens offline, en dat helpt de zaak niet.

Het upgraden naar een nieuwe minor release daarentegen hoeft niet veel meer te zijn dan het vervangen van de binaries en het herstarten van de service, omdat daar geen verandering is in dat formaat, waardoor gebruikers dus vaak kiezen om maar eens elke 2 of 3 jaar een major version upgrade te doen.

Als laatste zijn er in de jaarlijkse release voor veel gebruikers niet verschrikkelijk veel nieuwe features die kritiek genoeg zijn dat de gebruiker ze direct wil gaan gebruiken. Dit is ook weer een punt voor gebruikers om even een makkelijke en korte minor version update te doen: de moeite om je applicatie te testen en valideren tegen de nieuwe PostgreSQL versie en de bijbehorende downtime wegen mogelijk niet op tegen de nieuwe features die je al dan niet gebruikt: De applicatie werkt al OK/goed genoeg, waarom zou er nu extra tijd in gestoken moeten worden?


Als we kijken naar bijvoorbeeld MySQL, dan zie je dat daar jaren lang voor hun versie 8.0 (die versie die de nieuwe features kreeg sinds 2018) er geen losse release was waarin enkel bugs gefixed werden: er werden zowel nieuwe features in gebouwd als bugs in gefixed. Maar met nieuwe features komen ook waarschijnlijk nieuwe bugs and potentiele performance issues. Veel gebruikers bleven daarom op versie 5.7 steken om een versie te hebben die geen nieuwe bugs of performanceproblemen zou krijgen. Maar omdat 5.7 in oktober 2023 EOL zou gaan zou dat echter een probleem worden voor deze gebruikers, dus heeft Oracle sinds vorig jaar het release-proces van MySQL aangepast zodat er nu wel een versie is die enkel bugfixes krijgt, wat dit probleem voor gebruikers van MySQL opgelost heeft.

[scholtnp]

Nee, dat denk ik niet. Je gebruikt voor backup, export en import gewoon het SQL formaat, zie hier. Een nieuwe versie starten met de oude directories is voor zover ik weet niet aanbevolen omdat het binaire formaat kan wijzigen bij nieuwe major releases. Maar de vele versies bestaan omdat er lange support periodes gelden voor de diverse Linux distributies.

[rbr320]

Als je gebruik maakt van de PostgreSQL versie die uit de repository van je (LTS) distro komt dan is het ook de verantwoordelijkheid van de distro-maintainers om te zorgen dat security patches en bugfixes worden gebackport naar de versie van PostgreSQL die ze ondersteunen. Dat PostgreSQL zelf nog lange tijd hun oudere versies ondersteunt maakt dat natuurlijk makkelijker, maar er zijn zeker LTS distro's die nog gebruik maken van een PostgreSQL versie die voor de ontwikkelaars al lang EOL is.

[Verwijderd]

Redhat maakt het wel heel gortig als het gaat om beschikbaarheid van PostgreSQL op hun platform.

Versie 9.6 is naar mijn weten nog steeds de enige versie van PostgreSQL die beschikbaar is in hun repository. Het is ondertussen wel best practice te noemen om gewoon de repositories te nemen die beschikbaar zijn vanuit PostgreSQL zelf en juist niet van de distributies.

[rbr320]

Ik weet niet waar je die informatie vandaan haalt, maar het klopt niet.

• De repository van RHEL7 bevat PostgreSQL 9.2. Die versie is stokoud, maar dat is RHEL7 inmiddels ook.
• In de repository van RHEL8 vind je inderdaad PostgreSQL 9.6, maar dankzij het AppStream systeem kan je ook kiezen voor PostgreSQL versie 10, 12, 13 of 15. Daarbinnen lijkt versie 12 een soort LTS versie te zijn met de langste ondersteuning. PostgreSQL 9.6 in RHEL8 is al EOL en bij een schone installatie van RHEL8 is de module voor PostgreSQL 10 de standaard.
• RHEL9 komt standaard met PostgreSQL 13 maar heeft ook een module voor versie 15.

Meer informatie over AppStream modules en hun lifecycle vind je hier.

Die "best practice" is waarschijnlijk ontstaan in de tijd van RHEL7, toen AppStream nog niet bestond. Wat mij betreft is het met RHEL8 of RHEL9 niet meer nodig. Als je een licentie hebt voor EnterpriseDB, de commerciële versie van PostgreSQL, zal je wel die specifieke repositories moeten gebruiken.

Daarnaast worden er in de enterprise wereld natuurlijk nog andere Linux distributies gebruikt zoals Ubuntu, waarbij je inderdaad de repositories op postgresql.org zult moeten gebruiken om PostgreSQL te upgraden als je nog met een oudere LTS versie werkt. Hoe het op SLES werkt zou ik je niet kunnen vertellen, daar heb ik geen ervaring mee.

[Reactie gewijzigd door rbr320 op 22 juli 2024 23:56]

[Mattashii]

Een nieuwe versie starten met de oude directories is voor zover ik weet niet aanbevolen omdat het binaire formaat kan wijzigen bij nieuwe major releases

Dit is niet geheel juist. Alhoewel je inderdaad niet een kopie van de gegevensmap waar PostgreSQL zijn gegevens in opslaat (PostgreSQL geeft dan al heel vlug een harde error, en start niet op), betekent dit niet direct dat alles via SQL migreren de beste en vlugste optie is:

De pg_upgrade-tool staat je toe om op een veilige manier de database te upgraden zonder dat hierbij alle data opnieuw in een database geladen hoeft te worden. Hierbij word enkel de metadata (dus welke tabellen, indexen, views, functies, etc. allemaal bestaan) in een nieuwe database van de nieuwe versie geladen, en daarna worden de data-bestanden van de vorige versie gelinkt in de nieuwe versie. Dit scheelt behoorlijk bij grote databases, en hoef je dus ook niet verschrikkelijk veel extra schijfruimte voor te bereiden.


Echter, wat wel een punt is, en waar ik denk waar je op doelt met "omdat het binaire formaat kan wijzigen bij nieuwe major releases", is dat je niet zomaar andere zaken ook kan updaten en verwachten dat het goed gaat.

Een goed voorbeeld is "glibc", een veelgebruikte tool in linux-omgevingen. Deze tool wordt gebruikt als o.a. bron van locale-gegevens zoals tekst-sorteervolgordes, en als die tool geupdate wordt komt het nog wel eens voor dat deze sorteringen subtiel (of gigantisch) anders worden. Omdat de opgeslagen data bij een upgrade niet verandert, kan het dus zijn dat indexes die gebouwd zijn op de sortering van een vorige versie van glibc ineens niet meer in de "correcte" volgorde staan volgens de nieuwe versie van glibc; maar dat ligt niet aan de upgrade van PostgreSQL zelf, maar aan het updaten van de onderliggende versie van glibc. Vaak is het echter verstandig om dit gezamenlijk te doen, omdat je dan minder tijd kwijt bent.

Dit is ook waarom je vaak je database opnieuw wil indexeren nadat je je databaseserver geupgraded hebt of verplaatst hebt naar een nieuw OS: De sortering van tekst kan anders zijn voor die server/dat OS, en dus moet je dit ook opnieuw in je indexes "bakken". Echter, het opnieuw indexeren van bestaande data is nog steeds vrijwel altijd vlugger dan het moeten indexeren van nieuwe data, en daarmee is een binaire update nog steeds sneller dan het dumpen en opnieuw inladen van de data via SQL.

[scholtnp]

Goed om te weten. Ik deed tot nu toe alles via pg_dump (Matrix server, 10Gbyte) omdat ik de hele migratie procedure eerst wou testen voordat ik het definitief uit ging te voeren. Halverwege stoppen en langdurig uit de lucht zijn vanwege onvoorziene problemen leek me niet fijn. En omdat ik liever een clean install van een Linux LTS distributie doe moet ik de data toch verplaatsen. Maar inderdaad, als het op een andere disk of partitie dan het OS staat en het veel data is, dan is de pg_upgrade_tool waarschijnlijk vlotter. Iets voor toekomstige migraties.

[Verwijderd]

Een Major upgrade is een migratie traject. dump/restore is nauwelijks te doen als je een DB van meerdere TB groot. En major versies van PG komen best rap opvolgend uit.
PG12 is bijvoorbeeld uit eind 2019.

Ik snap dat ze het niet hoeven doen, zo lang versies supporten (al is bijv. in het geval van PG12 5 jaar niet eens ongebruikelijk), maar ik ben er wel blij mee. We doen aan upgrades, maar er is wel een traject voor nodig.

[bzzzt]

Het is ook mogelijk online te migreren door logische replicatie te doen naar een tweede node, dat is in principe niet zo moeilijk. Het migratie traject bestaat vooral uit het controleren of er geen performance regressies optreden; major updates hebben vaak ook tweaks voor de query planner die soms totaal andere oplossingen kiest na een update.

[1F4A9]

Dat gaat inderdaad niet heel erg soepeltjes, want de database directory moet worden omgezet en daarvoor moet je een script draaien terwijl beide versies geinstalleerd zijn. Alternatief een een dump en restore, maar dat kan heel lang duren. Maar de voornaamste reden is denk ik dat Linux distros, met name de LTS versies die op servers draaien, vaak niet de nieuwste versies ondersteunen, al kan je die vaak wel via het PostgreSQL repository installeren.

[cariolive23]

Blijf het bijzonder vinden; waarom worden er zoveel versie blijvend gesupport?

Omdat er 1x per jaar een major release plaatsvindt. Je moet er niet aan denken om ieder jaar weer een upgrade te doen naar een nieuwe major version.

Is het zo slecht migreren tussen verschillende versies van deze database?

Nee hoor, dat valt reuze mee!

Iedere versie wordt 5 jaar ondersteunt. En omdat er elk jaar een nieuwe versie is, krijg je dus ook patches voor alle versies.

[rbr320]

Voor hen die PostgreSQL gebruiken op RHEL en zijn afgeleiden en deze aankondiging hebben gemist, zoals de DBA'ers binnen de organisatie waarin ik momenteel werk: de GPG sleutels waarmee de packages worden ondertekend zijn vervangen.

[Vordreller]

Several fixes for logical replication.

Ja, dan vraag je je af wat er mis was in de vorige versies. Om paranoïde van te worden.

[perlboy]

Als je genoeg opslagruimte hebt (zeg maar 2.5 maal huidige database grootte) of in staat bent om van een SAN een nieuw file systeem voor de nieuwe major upgrade data aan te maken dan is pg_upgrade je vriend (in copy mode zodat je veilig terug kunt). Maar je zal hoe dan ook bij een major upgrade je database offline moeten halen. Pg_upgrade is er sinds versie 12 meen ik.