Amazon Redshift ne prendra plus en charge la création de nouvelles fonctions Python définies par l’utilisateur à compter du 1er novembre 2025. Si vous souhaitez utiliser des fonctions Python définies par l’utilisateur, créez-les avant cette date. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement. Pour plus d’informations, consultez le billet de blog .

Opérations d’écriture et de lecture/écriture

Vous pouvez gérer le comportement spécifique des opérations d’écriture simultanées en décidant quand et comment exécuter différents types de commandes. Les commandes suivantes sont pertinentes pour cette discussion :

Les opérations COPY et INSERT sont de pures opérations de lecture/écriture. Les opérations DELETE et UPDATE sont des opérations de lecture/écriture (pour les lignes à supprimer ou à mettre à jour, elles doivent d’abord être lues). Les résultats des opérations d’écriture simultanées dépendent des commandes spécifiques qui sont exécutées simultanément.

Les opérations UPDATE et DELETE se comportent différemment, car elles s’appuient sur une table initiale lue avant toute écriture. Comme les transactions simultanées sont invisibles les unes aux autres, les opérations UPDATE and DELETE doivent lire un instantané des données depuis la dernière validation. Lorsque la première opération UPDATE ou DELETE libère son verrou, la deuxième opération UPDATE ou DELETE doit déterminer si les données qu’il va utiliser sont potentiellement obsolètes. Elles ne le sont pas, car la deuxième transaction n’obtient pas son instantané des données tant que la première transaction n’a pas libéré son verrou.

Situation de blocage potentiel pour les transactions d’écriture simultanées impliquant plusieurs tables

Quand les transactions impliquent des mises à jour de plusieurs tables, il y a toujours la possibilité que les transactions soient bloquées quand elles essaient d’écrire sur le même ensemble de tables. Une transaction libère tous les verrous de table à la fois lors d’une validation ou d’une annulation ; elle ne les libère pas un à la fois.

Par exemple, supposons que les transactions T1 et T2 commencent approximativement en même temps. Si T1 commence à écrire dans la table A et T2 commence à écrire dans la table B, les deux transactions peuvent se poursuivre sans conflit. Cependant, si T1 finit d’écrire sur la table A et doit commencer à écrire sur la table B, elle ne sera pas en mesure de poursuivre, car T2 continue de maintenir le verrou sur B. De même, si T2 finit d’écrire sur la table B et doit commencer à écrire sur la table A, elle n’est pas en mesure de poursuivre, car T1 continue de maintenir le verrou sur A. Comme aucune transaction ne peut libérer les verrous tant que toutes les opérations d’écriture ne sont pas validées, aucune transaction ne peut se poursuivre. Afin d’éviter ce genre de blocage, vous devez planifier soigneusement les opérations d’écriture simultanées. Par exemple, vous devez toujours mettre à jour les tables dans le même ordre des transactions et, si vous spécifiez des verrous, verrouillez les tables dans le même ordre avant d’effectuer les opérations DML.

Situation de blocage potentiel pour les transactions d’écriture simultanées impliquant une seule table

Dans un environnement d’isolement d’instantané, des blocages peuvent se produire lors de l’exécution de transactions d’écriture simultanées sur la même table. Le blocage de l’isolement d’instantané se produit lorsque des instructions INSERT ou COPY simultanées partagent un verrou et progressent, et qu’une autre instruction doit effectuer une opération (UPDATE, DELETE, MERGE ou DDL) nécessitant un verrou exclusif sur la même table.

Réfléchissez au scénario suivant :

Transaction 1 (T1) :

INSERT/COPY INTO table_A;

Transaction 2 (T2) :

INSERT/COPY INTO table_A; 
            <UPDATE/DELETE/MERGE/DDL statement> table_A

Un blocage peut se produire lorsque plusieurs transactions comportant des opérations INSERT ou COPY sont exécutées simultanément sur la même table avec un verrou partagé, et que l’une de ces transactions suit son opération d’écriture pure par une opération nécessitant un verrou exclusif, telle qu’une instruction UPDATE, MERGE, DELETE ou DDL.

Pour éviter le blocage dans ces situations, vous pouvez séparer les instructions nécessitant un verrouillage exclusif (instructions UPDATE/MERGE/DELETE/DDL) d’une transaction différente afin que toutes les instructions INSERT/COPY puissent progresser simultanément et que les instructions nécessitant des verrous exclusifs puissent être exécutées après elles. Sinon, pour les transactions comportant des instructions INSERT/COPY et MERGE/UPDATE/MERGE sur la même table, vous pouvez inclure une logique de nouvelle tentative dans vos applications afin de contourner les blocages potentiels.