Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Général » Problème sur requete UPDATE avec select for update » 06/12/2019 09:46:15
Voici les réponse que je peux apporter:
Qu'un LIMIT 1 ramène plus qu'une ligne parait assez extraordinaire. Peut-on en savoir plus sur le contexte:
- quelle est la définition de la table, index compris?
Voici la définition de la table MESSAGE:
CREATE TABLE MESSAGE
( id BIGSERIAL NOT NULL,
date_creation TIMESTAMP(6) WITH TIME ZONE DEFAULT now() NOT NULL,
identifier CHARACTER VARYING(110) NOT NULL,
...
queue_id INTEGER,
is_dequeued BOOLEAN DEFAULT false NOT NULL,
contenu JSON,
CONSTRAINT pk_message PRIMARY KEY (id),
CONSTRAINT fk_message_queue FOREIGN KEY (queue_id) REFERENCES "queue" ("id"),
CONSTRAINT unique_message_identifier UNIQUE (identifier)
);et les index correspondants:
TABLE_CAT TABLE_SCHEM TABLE_NAME NON_UNIQUE INDEX_QUALIFIER INDEX_NAME TYPE ORDINAL_POSITION COLUMN_NAME ASC_OR_DESC CARDINALTIY PAGES FILTER_CONDITION
--------- ----------- ---------- ---------- --------------- ------------------------- ---- ---------------- ----------- ----------- ----------- ----- ----------------
(null) core message false (null) pk_message 3 1 id A 0.0 29 (null)
(null) core message false (null) unique_message_identifier 3 1 identifier A 0.0 76 (null)- le niveau d'isolation est-il read committed (le niveau par défaut) ou autre?
C'est le niveau par défaut (read commited)
- est-ce que toutes les transactions qui utilisent la table sont dans le même niveau d'isolation?
- qu'est-ce qu'il y a comme autres comme opérations concurrentes probables sur la table (INSERT? DELETE?)
Sinon aucune autre opération effectuée en même temps
- est-ce que message.id peut changer? est-ce que message.id_queue peut changer?
Cette requête nous l'avons extraite de notre programme et nous l’exécutons manuellement pour la tester et nous arrivons par moment à refaire le problème. Donc les identifiants sont fixés à la main dans la requête et le problème est toujours là
#2 Re : Général » Problème sur requete UPDATE avec select for update » 03/12/2019 16:24:02
Si j'arrive à reproduire l'erreur car cela n'arrive pas souvent....j exécuterai un plan d’exécution pour en savoir plus.
Nous souhaitons dépiler des messages présent dans des queues en mettant à jour une colonne is_dequeued à TRUE.
Pour cela on récupère les messages d'une queue donnée Q et qui sont à is_dequeued = FALSE et on met à jour cette colonne à TRUE pour les messages récupérées.
ps: la limite n'est pas toujours de 1 c'est pour cela que nous avons un IN et non pas un = pour la clause WHERE
#3 Général » Problème sur requete UPDATE avec select for update » 03/12/2019 12:09:13
- mimst
- Réponses : 8
Voici ma requete posant problème :
UPDATE message SET is_dequeued = true
WHERE id IN (SELECT f2.id FROM message f2 WHERE f2.id_queue = 5 AND f2.is_dequeued = false ORDER BY f2.id ASC FOR UPDATE SKIP LOCKED LIMIT 1)
returning *
Lorsque nous avons cette requête avec "LIMIT 1", la requête va parfois nous retourner plusieurs résultats... alors que lorsqu'on exécute uniquement le "select" il retourne uniquement 1 ligne....
Et ceci est aléatoire...dans la plupart des cas on a bien le bon résultat avec une ligne retournée et parfois il en retourne plusieurs...
Je ne vois pas d où ca vient...
Pages : 1