Re: surprenant résultat : rollback sur update après pg_dump

Salut,

est ce que par hasard la variable autocommit aurait la valeur "off" ?

Si c'est le cas soit vous l'activez, soit vous démarrez et commitez
explicitement une transaction dans votre script ?

Le jeu. 29 août 2019 à 09:36, Cloc <ccastello(at)athmo(dot)eu> a écrit :

> Bonjour.
>
> En vue d'un travail spécifique de développement, j'ai besoin de la copie
> d'une base interne. J'ai voulu déplacer, upgrader et adapter cette base
> via un script bash, sur CentOS.
>
> Initialement, la base est en version 9.3. Je la migre sur un serveur
> CentOS 7, en version 11. Pas de configuration particulière.
> Un fichier pgpass est créé au début du script.
>
> Voici le script utilisé (tronqué et avec des noms modifiés)
>
> # pg_dump -h $PRODUCTION -U $USER_INITIAL --clean --create $MABASE >
> dump.sql
> # su - $PROPRIO_ACTUEL -c 'psql ' < dump.sql
> # REQUETE_PURGE="update tableune set nom = '', groupes = null where
> id_externe = any (select distinct id from contrat where ladate <
> '2019-01-01'::date);"
> # echo $REQUETE_PURGE | psql -h 127.0.0.1 -U $PROPRIO_ACTUEL -w -d $MABASE
> UPDATE 125834
>
> Puis dans la foulée, au sein du script, je vérifie et affiche le
> résultat d'un select. Il est cohérent (le résultat est égal à 0 si
> l'update est effectué) :
> # echo "select count (id) from tableune where id_externe = 25;" | psql
> -h 127.0.0.1 -U bddopserv -w -d archivage
>
> Le script laisse tomber PostgreSQL et effectue différentes manipulations
> sur des fichiers puis quitte tranquillement. Le nouveau serveur de dév
> est redémarré.
>
> Tout semble bien s'être passé. Pourtant, dès le premier essai d'usage,
> je me rend compte que les requêtes de nettoyage ne semblent pas avoir
> été exécutées, comme s'il y avait eu un rollback. Une fois exécutées
> manuellement, tout rentre dans l'ordre.
>
> Qu'ai je omis de prendre en compte ?
>
> Claude
>
>
>