Next: Storage Management Up: Die Systemarchitektur Previous: Der Executor Contents
PostgreSQL verfügt über ein geniales Speichermanagement System. Alte Versionen von PostgreSQL (6.x.x und dergleichen) hatten massive Probleme mit dem Speichermanagement - vor allem mit Speicherlöchern. Bei einem Softwarepackage dieser Komplexität war das auch nicht weiter verwunderlich. Zwar hat das Core Team zu 6.4 Zeiten bereits eine Vielzahl von Bugs gefixt - dennoch war es notwendig, einen grundlegend neuen Mechanismus zu implementieren, der das Speichermanagement von Grund auf regelt.
Durch die Einführung von sogenannten 'Memory Contexts' ist das Entstehen von Speicherlöchern de facto unmöglich geworden. Jeglicher Speicher wird innerhalb eines Contexts alloziert. Wird der Context selbst gelöscht, werden auch alle Segmente freigegeben, die sich in diesem Context befinden. Wird Speicher mit palloc() angefordert, wird der Speicher automatisch im aktuellen Context reserviert.
Memory Contexts sind hierachisch organisiert. Die folgenden Contexts sind vordefiniert:
Wenn Sie also eine serverseitige Funktion implementieren, die mit dem Speicher etwas schlampig umgeht, ist auch das kein Problem, da PostgreSQL ohnehin sicherstellt, dass Speicher am Lebensende des Contexts wieder freigegeben wird. Klarerweise sollten Sie danach trachten, Speicher korrekt zu verwalten - kleine Bugs werden aber vom System verziehen.
Neben dem 'normalen' Speicher benötigt PostgreSQL auch Shared Memory, der für die Interprozesskommunikation von entscheidender Bedeutung ist. Dabei ist wichtig zu wissen, dass PostgreSQL den gesamten Shared Memory beim Startup reserviert. Ist das System erst einmal aktiv, wird kein zusätzlicher Shared Memory mehr angefordert. Das ist ansich nur ein kleines Detail - es wird aber auf diese Weise sichergestellt, dass das System nicht aufgrund von fehlendem Shared Memory gezwungen wird, den Dienst zu quittieren.