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

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

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

Je ne vois rien (mais je manque parfois d'imagination :) ) à part ne pas être en autocommit. Un \set AUTOCOMMIT off dans le .psqlrc de $PROPRIO_ACTUEL ?

On 29/08/2019 09:36, Cloc wrote:
> 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
>
>

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

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

Bonjour.

Le 29/08/2019 à 12:30, Tumasgiu Rossini a écrit :
> 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.

En vous remerciant pour vos suggestions.
Je vais les explorer dès que possible.

Salutations.

Claude

Le 29/08/2019 à 09:36, Cloc 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

peut-être ici :
-d $MABASE

> 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
Stéphane D.

La commande suivante me parait bizarre car le nom de la base n'y est pas
specifiée:

su - $PROPRIO_ACTUEL -c 'psql ' < dump.sql

On Mon, Sep 2, 2019 at 9:52 AM Stéphane Dunand <s(dot)dunand(at)sirap(dot)fr> wrote:

> Le 29/08/2019 à 09:36, Cloc 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
>
> peut-être ici :
> -d $MABASE
>
> > 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
> Stéphane D.
>
>
>

Le 12/09/2019 à 17:12, Nicky Larson a écrit :
> La commande suivante me parait bizarre car le nom de la base n'y est pas
> specifiée:
>
> su - $PROPRIO_ACTUEL -c 'psql ' < dump.sql

:) effectivement ça peut surprendre mais le dump est correctement exécuté.

Merci pour toutes vos tentatives d'aide.
Finalement, je me contente de faire les update à l'issue de tous les
traitements. Ça fonctionne même si intellectuellement je n'ai pas
compris où je me suis trompé.

Le jeu. 12 sept. 2019 à 17:13, Nicky Larson <said(dot)assemlal(at)gmail(dot)com> a
écrit :

> La commande suivante me parait bizarre car le nom de la base n'y est pas
> specifiée:
>
>
su - $PROPRIO_ACTUEL -c 'psql ' < dump.sql
>
>
Le dump est créé avec l'option --create, il contient donc les commandes de
création de la base, utiliser psql sans spécifier la base
est valide, cf. /docs/current/app-pgdump.html

> On Mon, Sep 2, 2019 at 9:52 AM Stéphane Dunand <s(dot)dunand(at)sirap(dot)fr> wrote:
>
>> Le 29/08/2019 à 09:36, Cloc 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
>>
>> peut-être ici :
>> -d $MABASE
>>
>> > 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
>> Stéphane D.
>>
>>
>>