Vous n'êtes pas identifié(e).

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

dverite a écrit :

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

Pied de page des forums

Propulsé par FluxBB