Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je m'interroge sur la requête type suivante : UPDATE table set user_id = 'xxx' where user_id is null limit 1
J'ai toujours pensé que cette requête était safe d'un point de vue concurrence, que même en cas de stress sur la db, même avec des milliers d'execution en parallèle, il ne pouvait pas y avoir d'écrasement d'une requête sur une autre.
Or, récemment, on m'a fait douté et indiqué que je devrais locker lors de l'update.
Je n'ai pas réussi à trouver d'info à ce sujet.
D'ou ma question,
Est il possible, qu'une meme ligne respectant la clause where (user_id is null) puisse être "sélectionneé" pour être updatée par deux requêtes en parallèle et que la dernier requête qui écrit, écrase la valeur de la premiere ?
Merci d'avance
Hors ligne
Bonjour,
Sur postgres au moins cet ordre fera bien ce qu'il est censé faire, et n'écrasera pas une ligne modifiée de manière concurrente, car le prédicat est revérifié en cas de modification concurrente, cf https://www.postgresql.org/docs/current … -COMMITTED
Julien.
https://rjuju.github.io/
Hors ligne
UPDATE n'admet pas de clause LIMIT en Postgres, donc la requête telle que proposée n'est pas possible.
Il faudrait plutôt poser la question avec une vraie requête, car la revérification que mentionne Julien en #2 ne suffit pas forcément quand il y a des sous-requêtes.
Vous pouvez tester les UPDATE concurrents à la main avec deux sessions psql en parallèle et des BEGIN COMMIT explicites.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Ha ok, merci, j'avais pas cette notion de limit, cette requête était faite sur mysql à l"époque, et je l'avais énoncé de mémoire.
du coup, on est obligé de faire du select for update j'imagine dans ce cas
Hors ligne
Pages : 1
