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

From: Cloc <ccastello(at)athmo(dot)eu>
To: Tumasgiu Rossini <rossini(dot)t(at)gmail(dot)com>, pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: surprenant résultat : rollback sur update après pg_dump
Date: 2019-08-29 09:23:36
Message-ID: 3cfd04db-eaaf-c682-afa5-41c31600ff0f@athmo.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

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
>
>

In response to

Responses

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Tumasgiu Rossini 2019-08-29 10:30:22 Re: surprenant résultat : rollback sur update après pg_dump
Previous Message Marc Cousin 2019-08-29 09:05:39 Re: surprenant résultat : rollback sur update après pg_dump