RE: crash pg_restore

From: Alain Benard <alain(dot)benard(at)inrae(dot)fr>
To: Bruno Friedmann <bruno(at)ioda-net(dot)ch>, "pgsql-fr-generale(at)postgresql(dot)org" <pgsql-fr-generale(at)postgresql(dot)org>
Subject: RE: crash pg_restore
Date: 2021-06-28 11:57:19
Message-ID: 1aa5a294f8d544689b66f58d94f1b232@IDFDCPRIPEXMU06.inra.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Bonjour,
Au final il semble bien que postgis soit responsable et notamment en raison de librairies un peu trop récente pour notre postgis 2.5.5. Nous allons donc basculer sur du postgis 3.0 avec postgres 12. Les restaurations se passent bien (donc les dumps ne sont pas altérés).
Merci pour votre aide.
Alain.

-----Message d'origine-----
De : Bruno Friedmann <bruno(at)ioda-net(dot)ch>
Envoyé : mercredi 23 juin 2021 21:18
À : pgsql-fr-generale(at)postgresql(dot)org
Objet : Re: crash pg_restore

> Merci Guillaume,
> J’ai mis max_parallel_workers = 1 (je ne sais si c’est vraiment ça
> qui désactive le parallélisme) et ça ne change rien. Je pense que ton
> incrimination de Postgis est certainement la bonne piste car on trouve
> quelques âmes malheureuses qui ont le même souci sans que j’ai vu de
> solution pour l’instant (par exemple :
> https://stackoverflow.com/questions/63433659/raster2pgsql-free-invalid
> -poin ter-aborted-core-dumped). J’ai essayé de restaurer le dump avec
> un script perl fournit avec Postgis (que j’ai déjà souvent utilisé par
> le passé pour des migrations) :
> /usr/pgsql-12/share/contrib/postgis-2.5/postgis_restore.pl – le
> résultat est le même. Pg_restore n’est donc pas le responsable comme
> tu le soulignais.
Je vais poursuivre mes recherches
> Alain.
>

C'est pas impossible que l'extension postgis utilisée (2.5.5 compilée avec un geos et un proj aussi récent ne va pas buggé.

A savoir que postgis 2.5.5 est comment dire un peu vieux (il y a 3.1) c'est un peu comme continuer à vouloir utiliser PG 9.2 tôt ou tard ça M....

Il y a un truc que j'utilise lorsque la restauration ou migration de base postgis se vautre (d'une manière peu élégante comme là ...) c'est d'utiliser l'outil pg_dump_all (donc sortie en mode texte, donc nécessite de la place, et souvent du temps), cela permet de remonter la base avec psql -f dumptralala.sql à savoir que vous pouvez limiter le "all" à une seule base.

C'est un peu le retour au burin avec pierre de taille, mais cela m'a déjà souvent sauver les miches avec les extensions caprisieuses ;-)

Dans tous les cas, je ferais un audit, pour vérifier si vos besoins et utilisation postgis 2 pourrait pas bénéficier d'un postgis 3.1 car sur un pg12 c'est tout de suite plus cohérent (support parallélisme et toute les nouveautés pg).

Bon dump, et restoration

--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
expertise en open-source

GPG KEY: E4720D8715B696B4
irc: tigerfoot

Computing freedom with openSUSE Tumbleweed - 20210618 Linux 5.12.12-1-default x86_64 GNU/Linux, nvidia: 460.84
Qt: 5.15.2, KDE Frameworks: 5.83.0, Plasma: 5.22.0, kmail2 5.17.2 (21.04.2)

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Alain Benard 2021-08-06 12:03:39 utilisation d'un index ou pas par le planificateur.
Previous Message Bruno Friedmann 2021-06-23 19:18:16 Re: crash pg_restore