Software-update: PostgreSQL 8.2.1

Gisteren is in de vorm van versie 8.2.1 de eerste update vrijgegeven voor de begin december uitgebrachte versie 8.2 van PostgreSQL. Deze populaire opensource Relational Database Management System draait op op een groot aantal besturingssystemen en is daardoor uitstekend inzetbaar in diverse omgevingen. De broncode is beschikbaar voor download op deze pagina, binaries voor Windows kunnen hier worden gevonden. Het is niet nodig om een dump/restore uit te voeren, wanneer er van versie 8.2 wordt gemigreerd. In deze release zijn de volgende veranderingen en verbeteringen doorgevoerd:

Changes

• Fix crash with SELECT ... LIMIT ALL (also LIMIT NULL)
• Several /contrib/tsearch2 fixes
• On Windows, make log messages coming from the operating system use ASCII encoding
  This fixes a conversion problem when there is a mismatch between the encoding of the operating system and database server.
• Fix Windows linking of pg_dump using win32.mak
• Fix planner mistakes for outer join queries
• Fix several problems in queries involving sub-SELECTs
• Fix potential crash in SPI during subtransaction abort
  This affects all PL functions since they all use SPI.
• Improve build speed of PDF documentation
• Re-add JST (Japan) timezone abbreviation
• Improve optimization decisions related to index scans
• Have psql print multi-byte combining characters as before, rather than output as \u
• Improve index usage of regular expressions that use parentheses
  This improves psql \d performance also.
• Make pg_dumpall assume that databases have public CONNECT privilege, when dumping from a pre-8.2 server
  This preserves the previous behavior that anyone can connect to a database if allowed by pg_hba.conf.

[break]

Versienummer	8.2.1
Besturingssystemen	Windows NT, Windows 2000, Linux, BSD, Windows XP, macOS, Solaris, UNIX, Windows Server 2003
Website	PostgreSQL
Download	http://www.postgresql.org/ftp/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (5)

[flowerp]

Ik ben momenteel aan het testen met 8.2.0 en tot zover nog geen problemen gevonden eigenlijk, maar goed om te zien dat er nu alweer een update is.

[Olaf van der Spek]

maar goed om te zien dat er nu alweer een update is.

Want updates zijn een doel op zich?

[flowerp]

Als je voor het bedrijf waar je werkt bepaald welke versies in produktie gaan dan zijn updates in zekere zin een doel op zich, bij wijze van spreke dan.

Waar het hier om gaat is dat 8.2 een geheel nieuwe versie is waarin veel nieuwe dingen zitten. Die ga je niet zomaar in produktie gebruiken voor de eerste update er is. Normaal gesproken test je, vind je eventueel wat problemen waarop je dan wacht tot de eerste update. Dit is bijvoorbeeld ook zo bij Tomcat 6, Java 6. 2 willekeurige paketten die zeer recent zijn, die ik meteen getest hebt in de eerste release maar waarvan nog geen (stable) update is uitgekomen.

Bij PostgreSQL komt men dus al met een bug fix release, nog voor dat ik zelf problemen in 8.2.0 had gevonden. Ik heb enkele 1000'en (!) regels SQL getest en tot nu toe draaide alles in mijn specificieke test stabiel.

[SUPR-ME]

Updates betekenen vaak een actieve ontwikkeling, maar dat weet je zelf ook waarschijnlijk wel.
Ik ben sinds kort overgestapt op 8.2 en heb al aardig wat verbeteringen gezien t.o.v. eerdere releases.

[JeRa]

Ik ben zelf een tijdje geleden overgestapt van MySQL op PostgreSQL voor een aantal van mijn applicaties om het één en het ander te testen.

Ik ben zéér te spreken over de mate van flexibiliteit in pgsql zelf; met name het definiëren van types en het kunnen integreren van willekeurige talen is geweldig. Ook het feit dat ik nu een applicatie kan schrijven die volledig met transacties werkt zonder er eerst InnoDB voor in te schakelen en te gebruiken met alle nadelen van dien, heeft ervoor gezorgd dat ik pgsql hoog in het vaandel heb staan.

Echter is er natuurlijk ook een keerzijde. Tsearch2, de (nog redelijk in ontwikkeling zijnde) full text search engine voor pgsql, biedt leuke opties maar in de praktijk is het werkelijk onwerkbaar. Indexeren duurt dagen (letterlijk!) waar de FT-search van MySQL indexeerde in ruim één of twee uur. Vervolgens is de rank()-functie zo traag dat het zoeken weliswaar snel is, maar het sorteren op relevantie een volledige minuut kan duren op sommige queries.

Ook de query planner is nog niet helemaal optimaal. Het lijkt alsof MySQL in de gaten heeft wélke join het snelst het aantal resultaten kort door de index al raad te plegen terwijl PostgreSQL puur plant op basis van wat algemene(re) statistieken. Een query met 8 joins (met dus heel veel mogelijke volgordes qua joinen) werd door MySQL moeiteloos geoptimaliseerd terwijl PostgreSQL al andere resultaten gaf als ik de initiële volgorde van de joins in de query aanpaste. Erg jammer dus.

Al met al biedt PostgreSQL dus voor mij veel voordelen maar ook de nodige nadelen - hopelijk zullen ze die in de toekomst nog weg weten te werken.