Re: Dump qui plante (pg 8.3.4)

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

In response to

Responses

Browse pgsql-fr-generale by date

  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)