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

Sans vouloir vous offenser, moi çà m'arrive donc je pars du
principe que tout le monde est aussi bête que moi :
vous êtes certain que la base que vous mettez à jour est bien celle
que vous interrogez par la suite ?

Je n'ai pas vraiment d'idées, a part la transaction.

Peut être que quelque part dans votre script vous "annulez" votre update ?
Vous devriez, si c'est possible et si vous ne l'avez pas déjà fait,
essayer une version "courte" de votre script, en isolant
la commande problématique.

Augmenter le détail des logs et les consulter serait une autre piste.

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

> Re.
>
> Je n'ai pas exploré cela. C'est chose faite :
> autocommit n'est défini nulle part. C'est donc la valeur par défaut qui
> s'applique : on
> Effectivement, après connexion via psql
> \echo :AUTOCOMMIT
> on
>
> J'ai aussi tenté :
> # REQUETE_PURGE="begin transaction ; update tableune set nom = '',
> groupes = null where id_externe = any (select distinct id from contrat
> where ladate < '2019-01-01'::date); commit transaction; "
> # echo $REQUETE_PURGE | psql -h 127.0.0.1 -U $PROPRIO_ACTUEL -w -d $MABASE
>
> Même résultat surprenant.
>
> Autre hypothèse ?
>
> Autre information : le serveur est virtualisé. Du coup, lors de la
> migration, nous n'avons défini que 1Go de RAM pour le système. Est-ce
> que cela pourrait jouer sur ce comportement ?
>
> Le 29/08/2019 à 10:43, Tumasgiu Rossini a écrit :
> > 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
> > <mailto: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
> >
> >
>