To sidebar

jeudi 8 octobre 2020

Le réchauffement climatique & PostgreSQL : interdire la glaciation

Un des défauts choix de l’implémentation de PostgreSQL est le numéro de transactions sur 32 bits, qui oblige à nettoyer périodiquement les vieux numéros de transaction sur chaque ligne en les marquant comme « gelés ». Cette opération se déroule lors d’un VACUUM FREEZE (doc), et elle est parfois assez embêtante.

Que se passe-t-il quand on croit bien faire en le désactivant ?

Lire la suite...

dimanche 13 mai 2018

VACUUM et agressivité

Le modèle MVCC de PostgreSQL a un avantage : une session ne s’embête pas à supprimer physiquement les données qu’elle a modifiées, et gagne ainsi du temps. De plus, ces lignes pourraient encore être utiles à une autre transaction. L’inconvénient, c’est qu’il va bien falloir s’en occuper plus tard — en théorie à un moment moins chargé.

Il faut donc effectuer régulièrement un VACUUM sur les tables modifiées pour éviter le bloat, la boursouflure, le gonflement, l’embonpoint né de ces lignes mortes qu’aucune transaction ne peut plus voir. Dans les versions antiques de PostgreSQL, le VACUUM devait être passé manuellement ; à présent il est déclenché en arrière-plan par le démon autovacuum.

La configuration par défaut suffit en général, mais quand il faut y toucher, les nombreux paramètres ne rendent pas la chose très lisible. Il y a bien sûr la doc que l’on peut déjà trouver en ligne, l’officielle ou chez Dalibo, ou encore ce billet chez 2nd Quadrant. Mais rien ne vaut un bon test.

Lire la suite...

jeudi 26 janvier 2017

Réplication avec PostgreSQL 9.6 : l'exemple minimaliste

Ce qui suit décrit le strict minimum pour mettre en place deux instances en réplication maître/esclave avec PostgreSQL 9.6.

Lire la suite...

© SQL & éléphant, after the WP Dusk To Dawn theme Propulsé par Dotclear