Mit PostgreSQL 9.3 lassen sich Datenbankblöcke, die auf Festplatte geschrieben werden, mit Prüfsummen versehen. Das kann die Diagnose von Festplattenproblemen erleichtern, indem etwaige Datenkorruption erkannt wird. Interessant ist das insbesondere für Systeme, die auf unsicherer Hardware laufen.
Ob Prüfsummen verwendet werden sollen, muss der Administrator beim Initialisieren der PostgreSQL-Instanz mittels des Kommandos
»initdb
«
und dessen neuen Kommandozeilenparameters
»--data-checksums
«
festlegen. Nachträglich kann dieses Feature weder aktiviert noch deaktiviert werden. Ferner gilt es immer gleich für sämtliche Datenbanken und -objekte.
Das Schreiben oder Checken der Prüfsummen findet auf Blockebene für alle Datenbankobjekte wie Tabellen oder Indexe statt. Für einzelne Objekte ist der Check der Prüfsummen nicht deaktivierbar. Auch muss beachtet werden, dass die Aktivierung der Prüfsummen Auswirkungen auf die Geschwindigkeit der Datenbank hat.
Bisher wurde insbesondere bei Änderungen an Daten, die mit Fremdschlüssel entsprechende Tabellen referenzieren, ein sogenannter
»FOR SHARE
«
- beziehungsweise
»FOR UPDATE
«
-Lock-Typ verwendet. Das Problem mit diesen Typen war, dass sie bei einer Vielzahl an nebenläufigen Änderungen zu massiven Sperrungen führten, was die Geschwindigkeit solcher Anwendungen erheblich sinken lassen konnte.
Mit der Version PostgreSQL 9.3 werden zwei neue Lock-Typen eingeführt:
»FOR KEY SHARE
«
und
»FOR NO KEY UPDATE
«
. Diese beiden Lock-Typen blockieren sich nicht mehr gegenseitig. Wird nun ein Tupel, das über einen Fremdschlüssel verfügt, aktualisiert, so wird für den Fall, dass der Schlüssel nicht Bestandteil der Aktualisierung ist, nun ein neuer
»FOR NO KEY UPDATE
«
-Lock angefordert.
Prüfungen der Fremdschlüsselintegrität selbst werden in PostgreSQL seit jeher über implizite Trigger realisiert. Diese verwenden anstelle von
»FOR SHARE
«
nun
»FOR KEY SHARE
«
. Das beschleunigt den Großteil der Anwendungen mit einem derartigen Anforderungsprofil. In der Regel werden sowieso Fremdschlüsselwerte als solche nur recht selten aktualisiert.
Schon seit geraumer Zeit wurde in der PostgreSQL-Community über sogenannte Background-Prozesse nachgedacht.