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