Re: surprenant résultat : rollback sur update ap rès pg_dump
Marc Cousin <[email protected]> Thu, 29 Aug 2019 11:05:39 +0200
| Newsgroups | gmane.comp.db.postgresql.french |
|---|---|
| Message-ID | <[email protected]> |
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FOLXgGl8n4gztv04YAwI4I9FV9RONyW3D Content-Type: multipart/mixed; boundary="OMtaotcyuwgQFEQSgFKwTJCq5lUkPP59N"; protected-headers="v1" From: Marc Cousin <[email protected]> To: [email protected] Message-ID: <[email protected]> Subject: =?UTF-8?Q?Re=3a_surprenant_r=c3=a9sultat_=3a_rollback_sur_update_ap?= =?UTF-8?B?csOocyBwZ19kdW1w?= References: <[email protected]> In-Reply-To: <[email protected]> --OMtaotcyuwgQFEQSgFKwTJCq5lUkPP59N Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: quoted-printable Je ne vois rien (mais je manque parfois d'imagination :) ) =C3=A0 part ne= pas =C3=AAtre en autocommit. Un \set AUTOCOMMIT off dans le .psqlrc de $= PROPRIO_ACTUEL ? On 29/08/2019 09:36, Cloc wrote: > Bonjour. >=20 > En vue d'un travail sp=C3=A9cifique de d=C3=A9veloppement, j'ai besoin = de la copie > d'une base interne. J'ai voulu d=C3=A9placer, upgrader et adapter cette= base > via un script bash, sur CentOS. >=20 > Initialement, la base est en version 9.3. Je la migre sur un serveur > 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. >=20 > Voici le script utilis=C3=A9 (tronqu=C3=A9 et avec des noms modifi=C3=A9= s) >=20 > # 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 null wh= ere > 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 $MAB= ASE > UPDATE 125834 >=20 > Puis dans la foul=C3=A9e, au sein du script, je v=C3=A9rifie et affiche= 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;" | psq= l > -h 127.0.0.1 -U bddopserv -w -d archivage >=20 > Le script laisse tomber PostgreSQL et effectue diff=C3=A9rentes manipul= ations > sur des fichiers puis quitte tranquillement. Le nouveau serveur de d=C3= =A9v > est red=C3=A9marr=C3=A9. >=20 > Tout semble bien s'=C3=AAtre pass=C3=A9. Pourtant, d=C3=A8s le premier = essai d'usage, > je me rend compte que les requ=C3=AAtes de nettoyage ne semblent pas av= oir > =C3=A9t=C3=A9 ex=C3=A9cut=C3=A9es, comme s'il y avait eu un rollback. U= ne fois ex=C3=A9cut=C3=A9es > manuellement, tout rentre dans l'ordre. >=20 > Qu'ai je omis de prendre en compte ? >=20 > Claude >=20 >=20 --OMtaotcyuwgQFEQSgFKwTJCq5lUkPP59N-- --FOLXgGl8n4gztv04YAwI4I9FV9RONyW3D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEErRJFoqQ1WmHC5to09vfGVovAkJ8FAl1nlWMACgkQ9vfGVovA kJ/l4AgAnXkAlOmy/z6/DVi4Rc03XlFcpRtIFbq9sbrD1EBRQPwIbV1DUKwOIvv1 XXeZLsv71mdrgmtBDvDqy5fX5rGdlO5YNKWAMCd+vmvb2OKgLP49bbx0iFJIMKiV 5/grVll7YWhFMCCHGB83wZT9qTMnnrs6ni6DIoaUaf2b8l7y7sSDYDkUkFRrjuYJ +h+R/33MY7SeCCsop3Btlqvb/86Tt8caPCQJDhALNykmrLwAZl/9JKhn6XO07XVC R2ArJ+q+XOK9vj7amiBZvHPaYTc8GpkC2177P7d3r6L8bKYY+ngJFRQqigu7/0rv 2zKcmtbCggbkHAGK4u394XUZLtQyYg== =h0Uf -----END PGP SIGNATURE----- --FOLXgGl8n4gztv04YAwI4I9FV9RONyW3D--