From: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
---|---|
To: | postgresql <pgsql-fr-generale(at)postgresql(dot)org> |
Cc: | philippe dhondt <philippe(dot)dhondt(at)tele2(dot)be> |
Subject: | Re: Dump qui plante (pg 8.3.4) |
Date: | 2008-11-03 13:35:25 |
Message-ID: | 490EFE1D.4090504@lelarge.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Guillaume Lelarge a écrit :
> [...]
> Ça ne m'étonne pas trop. Les verrous sont posés avant de commencer le
> dump des tables. J'ai fait un test hier soir en créant une base à 8000
> tables. Je n'ai pas le message d'erreur que vous indiquez. Je viens
> aussi de monter à 90 pour max_lock_per_transactions, aucun soucis.
>
> Quelle version de PostgreSQL utilisez-vous ?
> Pouvez-vous nous envoyer votre fichier de configuration complet ?
> Quelle est la taille de la base ?
> D'autres clients sont-ils connectés en même temps que vous ?
>
Comme la plupart de la conversation qui a suivi s'est faire en dehors de
la liste, juste un petit mail pour indiquer que la solution revient bien
à augmenter max_lock_per_transactions.
pg_dump réalise toute la sauvegarde dans une seule transaction. Il pose
un verrou AccessShare sur toutes les tables au lancement de la commande,
ce qui peut prendre du temps et beaucoup de verrous si vous avez un très
grand nombre de tables. Il se peut même que le serveur n'ait pas assez
de mémoire pour enregistrer tous les verrous. D'où la nécessiter
d'augmenter max_lock_per_transactions.
Philippe l'a déjà augmenté jusqu'à 150 et ce n'est toujours pas
suffisant. J'espère qu'il nous dira jusqu'où il a dû aller pour faire
son dump :)
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Christ | 2008-11-03 14:52:55 | Configuration de Slony |
Previous Message | Marc Cousin | 2008-10-31 19:41:02 | Re: Dump qui plante (pg 8.3.4) |