Software-update: PostgreSQL 8.4.2 / 8.3.9 / 8.2.15 / 8.1.19 / 8.0.23 / 7.4.27

PostgreSQL is een open source relational database management system dat op diverse besturingssystemen gedraaid kan worden. De ontwikkelaars hebben weer een reeks nieuwe versies uitgebracht met 8.4.2, 8.3.9, 8.2.15, 8.1.19, 8.0.23 en 7.4.27 als versienummers. Hiermee worden verschillende fouten opgelost en aangezien een daarvan een probleem met ssl-authenticatie betreft, wordt het iedereen aangeraden om te updaten. De aankondiging van deze versies ziet er als volgt uit:

PostgreSQL 2009-12-14 Security Update

The PostgreSQL Project today released minor versions updating all active branches of the PostgreSQL object-relational database system, including versions 8.4.2, 8.3.9, 8.2.15, 8.1.19, 8.0.23, and 7.4.27. This release fixes one moderate-risk and one low-risk security issue: an SSL authentication issue, and a privilege escalation issue with expression indexes. All PostgreSQL database administrators are urged to update your version of PostgreSQL at the earliest opportunity.

There are also 48 other bug fixes in this release, many of which apply only to version 8.4, and a few of which are specifically for Windows. While these are generally fixes for minor issues, among the changes are:

• Prevent hash index corruption
• Update time zone data for 9 regions
• Fix permissions-related startup issue on Windows
• Prevent server restart if a VACUUM FULL is killed
• Correct cache initialization startup bug

See the release notes for a full list of changes with details.

As with other minor releases, users are not required to dump and reload their database in order to apply this update release; you may simply shut down PostgreSQL and update its binaries. However, users who have hash indexes will want to run REINDEX after updating in order to repair any existing index damage. Users skipping more than one update may need to check the release notes for extra, post-update steps.

• Release Notes
• Installation Packages
• Source Code
• Details of Security Issues

The PosgreSQL Global Development Group will stop releasing updates for PostgreSQL versions 7.4 and 8.0 after June of 2010. We urge users of those versions to start planning to upgrade now.

Versienummer	8.4.2 / 8.3.9 / 8.2.15
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, Windows XP, Solaris, UNIX, Windows Server 2003, Windows Vista, Windows Server 2008
Website	PostgreSQL
Download	http://www.postgresql.org/download/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (35)

[s.stok]

Voor iedereen die naar PostgreSQL wil gaan overstappen kan ik dit absoluut aanbevelen!
Maar let wel, 1-op-1 over porten van MySQL naar PostgreSQL is niet altijd sneller

Het is verstandig om goed je query's analyseren en waar nodig aan te passen.
PostgreSQL heeft namelijk een andere manier van plannen dan MySQL.
Iets wat snel is in MySQL niet perse sneller in PostgreSQL.

Een paar interessante links over SQL.
En specifiek voor PostgreSQL (met onder andere een snel handleiding om over te stappen).

PostgreSQL heeft wat betreft populariteit lang in de schaduw van MySQL gestaan.
Onterecht als je het mij vraagd het bied veel meer ondersteuning dan MySQL, is commercieel veel interessanter (mag ook gesloten worden verspreid), is bij een hoge load veel stabieler (een corrupte database vergt dat je wel heel dom bezig bent).

Het is echt heel goed schaalbaar, zo kan je indexen op een aparte harde schijf zetten.
En is de cluster ondersteuning (EntepriceDB) veel beter door ontwikkeld.


Nu lijkt het misschien dat ik iedereen oproep om MySQL te dumpen, en over te stappen op PostgreSQL. En dat klopt , maar je krijgt dan wel een veel stabieler, sneller (mits je het goed doet), en eindeloze mogelijkheden!
Je kan wachten tot MySQL eindelijk komt met versie 6.0 of je kan overstappen naar PostgreSQL en direct profiteren van de mogelijkheden.

• Fulltext search (tsearch2)
• CommonTableExpression
• Tablespaces (data verspreid over apparte harde schrijven)
• User defined functions (in sql, pl/pgsql, perl, tcl, C)
• Een oneindige hoeveelheid records
• Inet datatype (voor IP-adressen, ondersteund ook IPv6!)
• Window functions
• Transactions (altijd)
• Foreign Keys (altijd)
• Table Inheritance

En nog veel meer

[cariolive23]

Kortom, van MySQL tot Oracle, met PostgreSQL kun je altijd aan de slag

Voor grotere databases met grote indexen ( > RAM ), zijn functionele indexen echt ideaal. De index wordt dan compact, past perfect bij jouw soort queries en zorgt dus razendsnel voor de juiste resultaten. Dit is ook iets wat je vrij eenvoudig later kan toepassen, je hoeft er in jouw applicaties/scripts geen rekening mee te houden.

EXPLAIN ANALYZE is je grootste vriend wanneer je de boel wilt versnellen, is echt onmisbaar.

[donderklik]

Is PostgreSQL nu nog de enige echte Open Source Database?Nu MySQL bijna in handen komt van Oracle?

[user109731]

Er is ook nog Firebird. Maar MySQL blijft open-source (ook al gaat Oracle closed-source verder, er zal direct een fork komen van de laatste open-source versie).

Ik gebruik zelf PostgreSQL erg veel en het is een prima alternatief voor MySQL (en andere databases). Stabieler, veiliger en stricter en pgAdmin is een prima tool

[Reactie gewijzigd door user109731 op 23 juli 2024 02:16]

[Amito]

Kan je PostgreSQL dan wel gratis gebruiken voor commercieel gebruik?

[SMGGM]

Geen probleem
Wil je professionele support dan moet je wel betalen, maar het gebruik voor commercieel en niet commercieel is volledig gratis.

[user109731]

Sure, het heeft de BSD-licentie. Er zijn wel bedrijven die support leveren, maar dat is niet verplicht.

Hier een lijstje met bekende PostgreSQL gebruikers...

[cariolive23]

Wanneer jij morgen de database AmitoSQL op de markt wilt brengen op basis van PostgreSQL, ga je gang. Wat je ook aan kosten in rekening brengt bij jouw klanten, je hoeft PostgreSQL in elk geval niet te betalen. En mocht je de source code van PostgreSQL aanpassen voor jouw product, ook die hoef je niet te doneren/publiceren.

Uiteraard worden bijdrages zeer gewaardeerd, maar het is niet verplicht.

Je hebt volledige vrijheid, dat is één van de kenmerken van het project.

[Fopper21]

Er zijn genoeg andere OSS databases, op het moment schijnen toch veel bedrijven te kijken naar niet relationele DBs, zoals CouchDB van Apache. Maar PostgreSQL heeft na MySQL volgens mij wel de grootste usebase als het gaat om OSS relationele DBs.

[Reactie gewijzigd door Fopper21 op 23 juli 2024 02:16]

[dsmink]

Ik heb nog geen flauw idee, maar ik zat er inmiddels wel naar te kijken. Ik denk dat het wel goed is om het pakket eens nader te bekijken en mogelijk eens te testen. Zelf ben ik redelijk thuis in het gebruik van MySQL. Heb het altijd een fijn pakket gevonden, maar begin nu toch wel voor de toekomst te vrezen van MySQL. PostgreSQL is dan zeker een pakket dat zijn positie zou kunnen overnemen. In ieder geval in mijn situatie!

[Verwijderd]

Ik ben slechts twee problemen tegengekomen met het gebruik van PHP icm Postgres ipv Mysql:
- Als je hoofdletters in tablenamen wilt hebben dan moet je altijd quotes gebruiken om je tabelnamen, erg vervelend.
- Mysql ondersteuning is nog steeds beter in PHP

[cariolive23]

- Als je hoofdletters in tablenamen wilt hebben dan moet je altijd quotes gebruiken om je tabelnamen, erg vervelend.

En erg onzinnig, de betekenis van de naam wordt er niet anders van. Oracle werkt overigens hetzelfde, maar dan uppercase.

- Mysql ondersteuning is nog steeds beter in PHP

Dat is nieuw, dat was vanochtend namelijk nog niet het geval. Klinkt alsof je nog nooit (goed) met PostgreSQL hebt gewerkt vanuit PHP, dan had je namelijk al lopen klagen over de gebrekkige ondersteuning van MySQL in PHP. Functies zoals pg_query_params() en pg_fetch_all() bestaan al jaren in PHP voor PostgreSQL, vergelijkbare functies voor MySQL zijn er niet of pas sinds MySQLi.

En wat dacht je van pg_put_line() om csv-content te streamen naar je database? Erg handig voor hoge performance.

Zie de lijsten met functies in PHP:
MySQL-functies
PostgreSQL-functies

Welke lijst is langer/completer? Niet dat je daar al te veel waarde aan mag hechten, maar het geeft wel aan dat je in PHP niets tekort komt voor het gebruik van PostgreSQL-databases.

Succes!

[s.stok]

En niet te vergeten het uitvoeren van meerdere query's in één functie.
Dit is pas ondersteund bij MySQLi, eigenlijk geluk bij een ongeluk want daardoor is het wel moeilijker om een SQL injection uit te voeren

En de licentie problemen omtrent MySQL lib.
Daardoor hebben ze een native driver ontwikkeld, MySQLnd (als ik het goed heb), maar dat door dat geintje kon MySQL ondersteuning niet standaard meer bij PHP voor Windows worden meegeleverd.

[Onno]

Ik ben slechts twee problemen tegengekomen met het gebruik van PHP icm Postgres ipv Mysql:
- Als je hoofdletters in tablenamen wilt hebben dan moet je altijd quotes gebruiken om je tabelnamen, erg vervelend.

Dat is wel heel erg de omgekeerde wereld, juist op dat gebied werkt MySQL ronduit maf. In PostgreSQL zijn identifiers gewoon case insensitive, tenzij je ze expliciet quote.

Als je dit doet:

create table BlaBla (...);

dan kun je vervolgens elk van de volgende statements gebruiken:

select * from blabla;
select * from BLABLA;
select * from BlaBla;

Alleen als je specifiek "BlaBla" gebruikt bij het maken van de tabel, zul je dat ook elders moeten doen. Precies hetzelfde geldt voor alle andere identifiers, zoals databasenamen en kolomnamen.

In MySQL is het een stuk rommeliger: tabelnamen zijn case sensitive, tenzij het bestandssysteem waarin ze opgeslagen worden dat niet is, en sommige andere identifiers zijn het juist weer nooit. Als je in MySQL:

create table BlaBla (...);

doet, is de enige manier om daar nog iets uit te krijgen dus ook

select * from BlaBla;

Het ontgaat me echt compleet hoe je dat handiger kunt vinden. (nog afgezien van wat elmuerte aanstipt, namelijk dat PostgreSQL gewoon doet wat de standaard zegt)

[zwippie]

Mijn grootste problemen met postgres:
- bijna geen enkele shared hoster biedt het aan
- webhosters hebben te weinig verstand van postgres waardoor je soms met een supertrage db zit te werken

Verder heb goed met postgres kunnen werken.

[flowerp]

Mijn grootste problemen met postgres:
- bijna geen enkele shared hoster biedt het aan

Maar dan heb je het ook wel over de absolute onderkant van de markt; de wereld van de Broodje van Kootje's van om de hoek die een 3 pagina tellend website'tje hebben en 100 hits per dag.

Voor dergelijke omgevingen maakt het eigenlijk helemaal niet uit welke DB je gebruikt en zou bij wijze van spreke Access nog voldoen. Als het maar select x from table where a = b; kan doen, dan is het al goed.

Als de keuze van een relationele DB wel uitmaakt voor jouw app, b.v. vanwege de hoeveelheid gegevens, de complexiteit van de queries of de integeriteit van je data, dan zit je natuurlijk allang niet meer op shared hosting. Zit je nog wel op shared hosting en denk je dat je een andere DB nodig hebt, dan is het waarschijnlijk verstandiger eerst eens naar een eigen host te gaan kijken en je daarna pas druk te maken over of PG nu wel of niet voor jou specifieke situatie beter is.

[elmuerte]

- Als je hoofdletters in tablenamen wilt hebben dan moet je altijd quotes gebruiken om je tabelnamen, erg vervelend.

Dat is nou eenmaal zo gedefinieerd in de SQL92 standaard. PostgreSQL en Firebird vinden het heel belangrijk om zich aan de standaard te houden.

[bulle bas]

Ik gebruik MySQL, niet omdat het beter is dan pg, maar wel omdat het ecosysteem een stuk aangenamer is.

MySQL is technisch inferieur aan pg, zo heeft het bijvoorbeeld altijd nog geen ondersteuning voor hash joins. Bizar. Maar de handige scipts en programma's eromheen (de MysqlGUI-tools, workbench, mysqldump etc) maken dat MySQL goed te administreren is.

[cariolive23]

Maar de handige scipts en programma's eromheen (de MysqlGUI-tools, workbench, mysqldump etc) maken dat MySQL goed te administreren is.

Dit soort tools bestaan toch ook voor PostgreSQL? Voor het maken van backups krijg je pg_dump en pg_dumpall, pgAdmin is een prima gratis GUI-tool en EMS Manager levert tools voor zowel PostgreSQL als MySQL. Ik zie niet waar je dan nog iets tekort zou komen.

De tools van Oracle en SQL Server zijn wel completer/beter, daar hangen dan ook wel iets andere prijskaartjes aan.

[bulle bas]

EMS Manager ziet er niet gratis uit.
MySQL Workbench zoals die nu in ontwikkeling is is gratis en een complete IDE, die je verder kun scripten. Ziet er zeer fraai uit en is multi-platform.
Dat heb ik nog nooit elders gezien, maar linkjes zijn welkom natuurlijk.

De tools van Oracle en SQL Server z

Nee ik vergelijk pg met mysql. Allebei OSS en graties.

[cariolive23]

EMS Manager ziet er niet gratis uit.

Beter kijken, de Lite-versie is gratis. Er zijn dan wat beperkingen, maar daar zul je niet snel last van hebben. Mocht je er wel last van hebben, dan draai je voldoende omzet om een licentie aan te schaffen.

Maar dan nog, pgAdmin3 kan alles wat nodig is om de databases te beheren en is nog overzichtelijk ook. En ook pgAdmin3 is multiplatform. Komt nog bij dat ik een database niet gebruik vanwege de tooling, maar vanwege zijn capaciteiten. Beheer doe ik tenslotte niet 24 uur per dag, 365 dagen per jaar, het gebruik gaat echter wel 24x365 door.

[freggy]

Er zijn al forks van MySQL ook, zoals MariaDB, gemaakt door de oorspronkelijke ontwikkelaar van MySQL (Monty).

[Azzmodan]

Alle drama over MySQL is natuurlijk wel omdat de oorspronkelijke eigenaar commercieel wou gaan en het vervolgens verkocht. Dat hij nu ineens toch verder wil knutselen aan MySQL is leuk maar ik heb niet echt vertrouwen dat de beste man het project zonder drama laat voorbestaan. Als ik een nieuwe database afhankelijke applicatie zou bouwen en MySQL niet meer leuk vind omdat ik bang ben dat Oracle er iets geks mee gaat doen dan zou ik ook Monty z'n MariaDB niet vertrouwen.

[Verwijderd]

Waarom niet vetrouwen dan? Omdat hij een uitgesproken mening heeft over de Oracle overname betekent niet dat hij niet een goed product kan afleveren. Hell, in de OSS wereld is er elke dag wel drama met Linus Torvalds (Linux kernel), Theo de Raadt (OpenBSD) en alle andere flink uitgesproken figuren. Vooralsnog staan hun producten als een huis.

[Azzmodan]

Die hebben niet allemaal hun project verkocht aan andere om vervolgens een fork te maken en je beklag te doen over hoe het door jou verkochte project word gerunt.

Ik heb ook niets verteld over dat het goede software zou zijn of niet (ik ben zelf van menig dat mysql een slecht product is kwa sql sever) maar dat als een overname door Oracle je bang maakt dan lijkt het me helemaal gek om naar de fork te gaan van degene die het in de eerste plaats heeft verkocht.

[freggy]

Misschien toch maar even de andere kant van het verhaal lezen. Zelfs de stelling dat Monty het zelf heeft verkocht, is blijkbaar slechts een interpretatie die niet zomaar eenduidig de waarheid is.

[BeosBeing]

Maar een bestaande op MySQL gebaseeerde applicatie ombouwen naar MariaDB zou ik wel overwegen als Oracle iets zou doen met MySQL waardoor ik het niet meer wil gebruiken.

Ombouwen naar PostgreSQL, Firebird of nog iets anders, kan mischien ook wel, maar zal meer werk zijn, ook dan is MariaDB mischien een zinvolle tussenstap.

[pasz]

Ik heb eigenlijk maar 1 nadeel kunnen ontdekken met PostgreSQL en dat is het gebruik van COUNT .... duurde lang !

[desmond]

Zonder verdere informatie zegt dit statement helaas niks en doe je PostgreSQL tekort.

Hoe zag de query er precies uit, inclusief where-clauses, joins etc? Hoe zijn de tabellen gemodelleerd en welke indexen, al dan niet geclustered, zijn er gedefinieerd? Ongetwijfeld zullen executieplannen flink kunnen verschillen tussen alle rdbms'en, maar het lijkt mij heel sterk als een straight count over 1 tabel geen vergelijkbare performance biedt aan andere dbms'en.

[cariolive23]

Helaas, dit is toch echt een zwak punt van PostgreSQL, zie de wiki:
http://wiki.postgresql.org/wiki/Slow_Counting

Zodra je echter een WHERE gaat gebruiken en een index hebt staan op je voorwaarden, dan gaat het weer als een speer. Dan wordt deze index gebruikt en hoeft er geen sequential scan te worden uitgevoerd. Maar een plain simple COUNT op alle records, die is (te) langzaam.

[desmond]

Op die wikipagina staat uitgelegd dat dit een uitvloeisel is van de implementatie van een methode om data consistency te waarborgen: MVCC. Even doorklikken leert dat MVCC een veelgebruikte database techniek is die wordt toegepast door zowat alle grote open en closed source database leveranciers, waaronder Microsoft SQL Server 2005/8, Oracle, Sybase, MySQL met InnoDB/Falcon, Firebird, Berkely DB, etc.

Het is de toevoeging van additionele functionaliteit om ACID compliance te verbeteren wat het heeft veroorzaakt. Het doet zich dan ook voor op bovenstaande dbms'en. Ik denk dat ACM de juiste conclusie trekt m.b.t. MyISAM en InnoDB.

Met de trigger work-around moet je oppassen, want inserts zullen slechter performen - vooral op grote tabellen met veel inserts is het de vraag of dat opweegt tegen een snellere rowcount.

[Reactie gewijzigd door desmond op 23 juli 2024 02:16]

[cariolive23]

Met de trigger work-around moet je oppassen, want inserts zullen slechter performen - vooral op grote tabellen met veel inserts is het de vraag of dat opweegt tegen een snellere rowcount.

Klopt helemaal, dit is dan ook niet meer dan een workaround. Je gaat ergens iets inleveren, dat kan bv. tijd zijn bij de INSERT's, dat kan tijd zijn bij de SELECT of het kan de nauwkeurigheid zijn. Maar je gaat ergens iets inleveren, MVCC is (net zoals iedere andere oplossing) niet perfect.

Overigens kun je door goede configuratie van je database, het opstellen van een goed datamodel, aanmaken van de juiste indexen en het opstellen van de juiste queries nog steeds uitstekende performance behalen. Sterker nog, wanneer je het goed aanpakt, heb je nooit last van deze beperking en is het niet meer dan theorie.

[ACM]

Dat is niet een zwak punt dat alleen PostgreSQL heeft, want als je in MySQL een grote tabel in InnoDB hebt (en voor concurrent gebruik moet je wel) zit je met precies hetzelfde probleem.
Sterker nog, vziw is MyISAM een van de weinige database/opslagformaten waarbij uberhaupt een actuele rowcount met een simpele integer bij te houden is. Alle databases met transactiesupport zullen toch op een of andere manier nagaan of die actuele rowcount wel overeenkomt met jouw transactie.
En met PostgreSQL en InnoDB kom je dan op het aflopen van alle MVCC-data uit. Waarbij InnoDB het voordeel heeft dat ie dan met de (interne) primary key uit de voeten kan voor de zichtbaarheidsdata, terwijl PostgreSQL die informatie uit de records zelf moet halen.

[cariolive23]

Wanneer dat echt uit de hand loopt, maak je even een aparte tabelletje aan, vult deze met de gewenste gegevens en laat deze gegevens met wat triggers onderhouden. Doe je voortaan geen COUNT meer op tabel A maar op tabel X waar het resultaat van een count op tabel A reeds in staat.

Het is een lapmiddel, maar het is een keuze geweest bij het MVCC-model. Daar is dit probleem een gevolg van, MVCC heeft niet alleen maar voordelen...

[--Andre--]

Het staat nog altijd op mijn TODO lijkt om PostgreSQL eens te testen.