Discussion :

[ymoreau]

Bonjour,
Je suppose que ce genre de cas doit exister, mais je n'ai réussi à trouver de solution. Je voudrais modifier un champ sur plusieurs lignes, et récupérer les lignes qui ont été modifiées.

Plus précisément, j'ai une table avec une clé et un champ statut : un entier avec 3 valeurs (non traité, traitement en cours, traitement effectué). Je veux récupérer un certain nombre d'id (non traités) tout en changeant leur statut à traitement en cours.
La difficulté c'est que plusieurs clients peuvent s'exécuter en même temps, donc récupérer l'id et changer le statut doivent se faire sans qu'une autre requête puisse atteindre ces mêmes lignes.

Je ne vois pas comment faire ça de façon sure. Merci d'avance de tout conseil !

[vmolines]

Si vous voulez faire plusieurs opérations consistantes, vous devez englober vos requêtes dans une transaction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
BEGIN;
 
SELECT ... ;
 
UPDATE ... ;
 
COMMIT;

Vous pouvez lire cet article qui vous en dira plus long sur le sujet :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1

Sachant que le niveau d'isolation par défaut de postgre est repeatable read.

[estofilo]

Sachant que le niveau d'isolation par défaut de postgre est repeatable read.

Non, c'est read committed.

Pour la question initiale, dans ce mode, une requête du genre UPDATE... WHERE... RETURNING id peut suffire à répondre au problème posé, à mon sens.

SELECT FOR UPDATE est aussi couramment utilisé, combiné avec la mise à jour et le tout dans une transaction.

[vmolines]

Merci pour la correction

[ymoreau]

Ah tout simplement. Je ne savais pas que les transactions verrouillaient aussi la lecture aux autres sessions. Par contre l'article précise qu'il vaut mieux faire ce genre de requête en procédure stockée pour éviter un deadlock, mais j'imagine que qu'en cas de perte de connexion le serveur effectue un rollback et termine la transaction automatiquement non ?

La requête UPDATE... WHERE... RETURNING est exactement ce dont j'ai besoin, elle me semble plus simple à utiliser que SELECT FOR UPDATE. Pour quelle raison la seconde est couramment utilisée du coup ?

Edit : je viens de réaliser qu'on ne peut pas mettre de LIMIT dans une requête UPDATE, donc ça fait déjà une raison d'utiliser SELECT FOR UPDATE à la place.