Sauvegarde logique plantée

[Phil]

Merci à Jean-Pierre pour sa question :

"J'ai un pg_dump planté avec cette erreur.

2021-04-30 20:06:59.554 CEST [65964] postgres@xxxxx ERREUR: n'a pas pu obtenir un verrou sur la relation « xxxxx.install »
2021-04-30 20:06:59.554 CEST [65964] postgres@xxxxx INSTRUCTION : LOCK TABLE xxxxx.xxxxx IN ACCESS SHARE MODE NOWAIT
2021-04-30 20:06:59.572 CEST [65960] postgres@xxxxx LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
2021-04-30 20:06:59.572 CEST [65960] postgres@xxxxx LOG: fin de fichier (EOF) inattendue de la connexion du client avec une
transaction ouverte
2021-04-30 20:06:59.573 CEST [65966] postgres@xxxxx LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
2021-04-30 20:06:59.573 CEST [65966] postgres@xxxxx LOG: fin de fichier (EOF) inattendue de la connexion du client avec une
transaction ouverte
2021-04-30 20:06:59.573 CEST [65968] postgres@xxxxx LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
2021-04-30 20:06:59.573 CEST [65968] postgres@xxxxx LOG: fin de fichier (EOF) inattendue de la connexion du client avec une
transaction ouverte
2021-04-30 20:06:59.578 CEST [65970] postgres@xxxxx LOG: fin de fichier (EOF) inattendue de la connexion du client avec une
transaction ouverte
2021-04-30 20:06:59.580 CEST [65962] postgres@xxxxx LOG: fin de fichier (EOF) inattendue de la connexion du client avec une
transaction ouverte

Je pensais que les dumps ne pouvaient jamais planter car ils posaient des verrous pour empêcher les tables d'être supprimées"

Réponse :

C'est le cas sans parallélisme mais pg_dump a probablement été lancé en exécution parallèle avec --jobs. Dans ce cas, il peut se produire le phénomène suivant décrit dans la documentation (e.g en 13 : https://docs.postgresql.fr/13/app-pgdump.html) :

Réclamer des verrous exclusifs sur les objets de la base lors de l'exécution d'une sauvegarde parallélisée peut causer l'échec de la sauvegarde. La raison en est que le processus maître de pg_dump réclame des verrous partagés sur les objets que les processus fils vont sauvegarder plus tard pour s'assurer que personne ne les supprime pendant la sauvegarde. Si un autre client demande alors un verrou exclusif sur une table, ce verrou ne sera pas accepté mais mis en queue, en attente du relâchement du verrou partagé par le processus maître. En conséquence, tout autre accès à la table ne sera pas non plus accepté. Il sera lui-aussi mis en queue, après la demande de verrou exclusif. Cela inclut le processus fils essayant de sauvegarder la table. Sans autre précaution, cela résulterait en un classique « deadlock ». Pour détecter ce conflit, le processus fils pg_dump réclame un nouveau verrou partagé en utilisant l'option NOWAIT. Si le processus fils n'obtient pas ce verrou, quelqu'un d'autre doit avoir demandé un verrou exclusif entre temps, et il n'existe donc aucun moyen de continuer la sauvegarde. pg_dump n'a d'autre choix que d'annuler la sauvegarde.

Ce phénomène est susceptible de se produite avec toutes les versions supportées au 01/05/2021. Supprimer des tables en cours d'export peut faire planter un dump s'il est exécuté en mode parallèle. Il faut le lancer sans parallélisme. Ou, plus simplement, ne pas supprimer de tables pendant les exports.