Re: surprenant résultat : rollback sur update aprè s pg_dump
Tumasgiu Rossini <[email protected]> Thu, 29 Aug 2019 12:30:22 +0200
| Newsgroups | gmane.comp.db.postgresql.french |
|---|---|
| Message-ID | <CAJD9AWwW3aESTzfGwLbZ7GpfHNLt+S6nmRUhkOkPW0G4Brq0Ow@mail.gmail.com> |
--000000000000e6387505913efe14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sans vouloir vous offenser, moi =C3=A7=C3=A0 m'arrive donc je pars du principe que tout le monde est aussi b=C3=AAte que moi : vous =C3=AAtes certain que la base que vous mettez =C3=A0 jour est bien cel= le que vous interrogez par la suite ? Je n'ai pas vraiment d'id=C3=A9es, a part la transaction. Peut =C3=AAtre que quelque part dans votre script vous "annulez" votre upd= ate ? Vous devriez, si c'est possible et si vous ne l'avez pas d=C3=A9j=C3=A0 fai= t, essayer une version "courte" de votre script, en isolant la commande probl=C3=A9matique. Augmenter le d=C3=A9tail des logs et les consulter serait une autre piste. Le jeu. 29 ao=C3=BBt 2019 =C3=A0 11:23, Cloc <[email protected]> a =C3=A9c= rit : > Re. > > Je n'ai pas explor=C3=A9 cela. C'est chose faite : > autocommit n'est d=C3=A9fini nulle part. C'est donc la valeur par d=C3=A9= faut qui > s'applique : on > Effectivement, apr=C3=A8s connexion via psql > \echo :AUTOCOMMIT > on > > J'ai aussi tent=C3=A9 : > # REQUETE_PURGE=3D"begin transaction ; update tableune set nom =3D '', > groupes =3D null where id_externe =3D any (select distinct id from contra= t > where ladate < '2019-01-01'::date); commit transaction; " > # echo $REQUETE_PURGE | psql -h 127.0.0.1 -U $PROPRIO_ACTUEL -w -d $MABAS= E > > M=C3=AAme r=C3=A9sultat surprenant. > > Autre hypoth=C3=A8se ? > > Autre information : le serveur est virtualis=C3=A9. Du coup, lors de la > migration, nous n'avons d=C3=A9fini que 1Go de RAM pour le syst=C3=A8me. = Est-ce > que cela pourrait jouer sur ce comportement ? > > Le 29/08/2019 =C3=A0 10:43, Tumasgiu Rossini a =C3=A9crit : > > 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=C3=A9marrez et commite= z > > explicitement une transaction dans votre script ? > > > > Le jeu. 29 ao=C3=BBt 2019 =C3=A0 09:36, Cloc <[email protected] > > <mailto:[email protected]>> a =C3=A9crit : > > > > Bonjour. > > > > En vue d'un travail sp=C3=A9cifique de d=C3=A9veloppement, j'ai bes= oin de la > copie > > d'une base interne. J'ai voulu d=C3=A9placer, upgrader et adapter c= ette > base > > via un script bash, sur CentOS. > > > > Initialement, la base est en version 9.3. Je la migre sur un serveu= r > > CentOS 7, en version 11. Pas de configuration particuli=C3=A8re. > > Un fichier pgpass est cr=C3=A9=C3=A9 au d=C3=A9but du script. > > > > Voici le script utilis=C3=A9 (tronqu=C3=A9 et avec des noms modifi= =C3=A9s) > > > > # pg_dump -h $PRODUCTION -U $USER_INITIAL --clean --create $MABASE = > > > dump.sql > > # su - $PROPRIO_ACTUEL -c 'psql ' < dump.sql > > # REQUETE_PURGE=3D"update tableune set nom =3D '', groupes =3D nul= l where > > id_externe =3D 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=C3=A9e, au sein du script, je v=C3=A9rifie et aff= iche le > > r=C3=A9sultat d'un select. Il est coh=C3=A9rent (le r=C3=A9sultat = est =C3=A9gal =C3=A0 0 si > > l'update est effectu=C3=A9) : > > # echo "select count (id) from tableune where id_externe =3D 25;" | > psql > > -h 127.0.0.1 -U bddopserv -w -d archivage > > > > Le script laisse tomber PostgreSQL et effectue diff=C3=A9rentes > manipulations > > sur des fichiers puis quitte tranquillement. Le nouveau serveur de > d=C3=A9v > > est red=C3=A9marr=C3=A9. > > > > Tout semble bien s'=C3=AAtre pass=C3=A9. Pourtant, d=C3=A8s le prem= ier essai > d'usage, > > je me rend compte que les requ=C3=AAtes de nettoyage ne semblent pa= s avoir > > =C3=A9t=C3=A9 ex=C3=A9cut=C3=A9es, comme s'il y avait eu un rollbac= k. Une fois ex=C3=A9cut=C3=A9es > > manuellement, tout rentre dans l'ordre. > > > > Qu'ai je omis de prendre en compte ? > > > > Claude > > > > > --000000000000e6387505913efe14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Sans vouloir vous offenser, moi =C3=A7=C3=A0 m'ar= rive donc je pars du</div><div>principe que tout le monde est aussi b=C3=AA= te que moi :<br></div><div>vous =C3=AAtes certain que la base que vous mett= ez =C3=A0 jour est bien celle</div><div>que vous interrogez par la suite ?<= /div><div><br></div><div>Je n'ai pas vraiment d'id=C3=A9es, a part = la transaction.</div><div><br></div><div>Peut =C3=AAtre que quelque part da= ns votre script vous "annulez"=C2=A0 votre update ?</div><div>Vou= s devriez, si c'est possible et si vous ne l'avez pas d=C3=A9j=C3= =A0 fait,</div><div> essayer une version "courte" de votre script= , en isolant</div><div>la commande probl=C3=A9matique.<br></div><div><br></= div><div>Augmenter le d=C3=A9tail des logs et les consulter serait une autr= e piste.<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"= gmail_attr">Le=C2=A0jeu. 29 ao=C3=BBt 2019 =C3=A0=C2=A011:23, Cloc <<a h= ref=3D"mailto:[email protected]">[email protected]</a>> a =C3=A9crit= =C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Re.<br> <br> Je n'ai pas explor=C3=A9 cela. C'est chose faite :<br> autocommit n'est d=C3=A9fini nulle part. C'est donc la valeur par d= =C3=A9faut qui<br> s'applique : on<br> Effectivement, apr=C3=A8s connexion via psql<br> \echo :AUTOCOMMIT<br> on<br> <br> J'ai aussi tent=C3=A9 :<br> #=C2=A0 REQUETE_PURGE=3D"begin transaction ; update tableune set nom = =3D '',<br> groupes =3D null where id_externe =3D any (select distinct id from contrat<= br> where ladate < '2019-01-01'::date); commit transaction; "<b= r> # echo $REQUETE_PURGE | psql -h 127.0.0.1 -U $PROPRIO_ACTUEL -w -d $MABASE<= br> <br> M=C3=AAme r=C3=A9sultat surprenant.<br> <br> Autre hypoth=C3=A8se ?<br> <br> Autre information : le serveur est virtualis=C3=A9. Du coup, lors de la<br> migration, nous n'avons d=C3=A9fini que 1Go de RAM pour le syst=C3=A8me= . Est-ce<br> que cela pourrait jouer sur ce comportement ?<br> <br> Le 29/08/2019 =C3=A0 10:43, Tumasgiu Rossini a =C3=A9crit=C2=A0:<br> > Salut,<br> > <br> > est ce que par hasard la variable autocommit aurait la valeur "of= f" ?<br> > <br> > Si c'est le cas soit vous l'activez, soit vous d=C3=A9marrez e= t commitez<br> > explicitement une transaction dans votre script ?<br> > <br> > Le=C2=A0jeu. 29 ao=C3=BBt 2019 =C3=A0=C2=A009:36, Cloc <<a href=3D"= mailto:[email protected]" target=3D"_blank">[email protected]</a><br> > <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">cca= [email protected]</a>>> a =C3=A9crit=C2=A0:<br> > <br> >=C2=A0 =C2=A0 =C2=A0Bonjour.<br> > <br> >=C2=A0 =C2=A0 =C2=A0En vue d'un travail sp=C3=A9cifique de d=C3=A9v= eloppement, j'ai besoin de la copie<br> >=C2=A0 =C2=A0 =C2=A0d'une base interne. J'ai voulu d=C3=A9place= r, upgrader et adapter cette base<br> >=C2=A0 =C2=A0 =C2=A0via un script bash, sur CentOS.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Initialement, la base est en version 9.3. Je la mig= re sur un serveur<br> >=C2=A0 =C2=A0 =C2=A0CentOS 7, en version 11. Pas de configuration parti= culi=C3=A8re.<br> >=C2=A0 =C2=A0 =C2=A0Un fichier pgpass est cr=C3=A9=C3=A9 au d=C3=A9but = du script.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Voici le script utilis=C3=A9 (tronqu=C3=A9 et avec = des noms modifi=C3=A9s)<br> > <br> >=C2=A0 =C2=A0 =C2=A0# pg_dump -h $PRODUCTION -U $USER_INITIAL --clean -= -create $MABASE ><br> >=C2=A0 =C2=A0 =C2=A0dump.sql<br> >=C2=A0 =C2=A0 =C2=A0# su - $PROPRIO_ACTUEL -c 'psql ' < dump= .sql<br> >=C2=A0 =C2=A0 =C2=A0#=C2=A0 REQUETE_PURGE=3D"update tableune set n= om =3D '', groupes =3D null where<br> >=C2=A0 =C2=A0 =C2=A0id_externe =3D any (select distinct id from contrat= where ladate <<br> >=C2=A0 =C2=A0 =C2=A0'2019-01-01'::date);"<br> >=C2=A0 =C2=A0 =C2=A0# echo $REQUETE_PURGE | psql -h 127.0.0.1 -U $PROPR= IO_ACTUEL -w -d<br> >=C2=A0 =C2=A0 =C2=A0$MABASE<br> >=C2=A0 =C2=A0 =C2=A0UPDATE 125834<br> > <br> >=C2=A0 =C2=A0 =C2=A0Puis dans la foul=C3=A9e, au sein du script, je v= =C3=A9rifie et affiche le<br> >=C2=A0 =C2=A0 =C2=A0r=C3=A9sultat d'un select.=C2=A0 Il est coh=C3= =A9rent (le r=C3=A9sultat est =C3=A9gal =C3=A0 0 si<br> >=C2=A0 =C2=A0 =C2=A0l'update est effectu=C3=A9) :<br> >=C2=A0 =C2=A0 =C2=A0# echo "select count (id) from tableune where = id_externe =3D 25;" | psql<br> >=C2=A0 =C2=A0 =C2=A0-h 127.0.0.1 -U bddopserv -w -d archivage<br> > <br> >=C2=A0 =C2=A0 =C2=A0Le script laisse tomber PostgreSQL et effectue diff= =C3=A9rentes manipulations<br> >=C2=A0 =C2=A0 =C2=A0sur des fichiers puis quitte tranquillement. Le nou= veau serveur de d=C3=A9v<br> >=C2=A0 =C2=A0 =C2=A0est red=C3=A9marr=C3=A9.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Tout semble bien s'=C3=AAtre pass=C3=A9. Pourta= nt, d=C3=A8s le premier essai d'usage,<br> >=C2=A0 =C2=A0 =C2=A0je me rend compte que les requ=C3=AAtes de nettoyag= e ne semblent pas avoir<br> >=C2=A0 =C2=A0 =C2=A0=C3=A9t=C3=A9 ex=C3=A9cut=C3=A9es, comme s'il y= avait eu un rollback. Une fois ex=C3=A9cut=C3=A9es<br> >=C2=A0 =C2=A0 =C2=A0manuellement, tout rentre dans l'ordre.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Qu'ai je omis de prendre en compte ?<br> > <br> >=C2=A0 =C2=A0 =C2=A0Claude<br> > <br> > <br> </blockquote></div></div> --000000000000e6387505913efe14--