Si le mécanisme de stockage sous-jacent à un FDW a un concept de verrouillage individuel des lignes pour prévenir des mises à jour concurrentes de ces lignes, il est généralement intéressant pour le FDW d'effectuer des verrouillages de niveau ligne avec une approximation aussi proche que possible de la sémantique utilisée pour les tables ordinaires de PostgreSQL. Ceci implique de multiples considérations.
Une décision clef à prendre est si il vaut mieux effectuer un verrouillage précoce ou un verrouillage tardif. Dans le verrouillage précoce, une ligne est verrouillée lorsqu'elle est récupérée pour la première fois à partir du stockage sous-jacent, alors qu'avec le verrouillage tardif, la ligne est verrouillée seulement lorsque le besoin est connu et nécessaire. (La différence survient parce que certaines lignes peuvent être abandonnées par des restrictions vérifiées localement ou des conditions de jointure.) Le verrouillage précoce est beaucoup plus simple et évite des allers-retours supplémentaires vers le stockage distant, mais il peut entraîner des verrouillages de lignes qui n'auraient pas eu besoin de l'être, résultant en une réduction de la concurrence voire même des deadlocks inattendus. De plus, le verrouillage tardif n'est possible seulement que si la ligne à verrouiller peut être identifiée de manière unique à nouveau plus tard. Idéalement, l'identifiant de ligne devrait identifier une version spécifique de la ligne, comme les TID de PostgreSQL le font.
Par défaut, PostgreSQL ignore les considérations de verrouillage lorsqu'il s'interface avec les FDW, mais un FDW peut effectuer un verrouillage précoce sans un support explicite du code du serveur principal. Les fonctions de l'API décrites dans le Section 56.2.5, qui ont été ajoutées dans la version 9.5 de PostgreSQL, autorise un FDW à utiliser un verrouillage tardif si il le désire.
Une considération supplémentaire est que dans le
niveau d'isolation READ COMMITTED
,
PostgreSQL peut avoir besoin de vérifier
à nouveau les restrictions et conditions de jointures avec une
version mise à jour de certaines lignes. Vérifier à nouveau
des conditions de jointure requiert d'obtenir à nouveau des
copies des lignes non ciblées qui étaient auparavant jointes
à la ligne cible. En travaillant avec des tables standards
PostgreSQL, ceci est effectué en
incluant les TID des tables non ciblées dans la liste des colonnes
projetées via la jointure, puis en récupérant à nouveau les
lignes non ciblées si nécessaire. Cette approche maintient
l'ensemble des données jointes compact, mais il demande une
capacité peu coûteuse de récupération à nouveau, ainsi qu'un TID
qui peut identifier de manière unique la version de la ligne à
récupérer à nouveau. Par défaut, donc, l'approche utilisée
avec les tables distantes est d'inclure une copie de la ligne
entière récupérée dans la liste de colonnes projetée via
la jointure. Ceci n'impose rien au FDW mais peut entraîner des
performances réduites des jointures par fusion ou hachage. Un FDW qui
remplit les conditions pour récupérer à nouveau peut choisir de
le faire.
Pour une commande UPDATE
ou
DELETE
sur une table distante, il est recommandé
que l'opération de ForeignScan
sur la table cible
effectue un verrouillage précoce sur les lignes qu'elle récupère,
peut-être via un équivalent de la commande SELECT FOR
UPDATE
. Un FDW peut détecter si une table est la cible
d'une commande UPDATE
/DELETE
lors de la planification en comparant son relid à
root->parse->resultRelation
,
ou lors de l'exécution en utilisant la fonction
ExecRelationIsTargetRelation()
. Une possibilité
alternative est d'effectuer un verrouillage tardif à l'intérieur
des fonctions callback ExecForeignUpdate
ou
ExecForeignDelete
, mais aucun support spécial
n'est fourni pour cela.
Pour les tables distantes qui sont verrouillées par une
commande SELECT FOR UPDATE/SHARE
, l'opération
ForeignScan
peut encore effectuer un verrouillage
précoce en récupérant des lignes avec l'équivalent de la commande
SELECT FOR UPDATE/SHARE
. Pour effectuer à la
place un verrouillage tardif, fournissez les fonctions callback
définies à Section 56.2.5. Dans
GetForeignRowMarkType
, sélectionner
l'option rowmark ROW_MARK_EXCLUSIVE
,
ROW_MARK_NOKEYEXCLUSIVE
,
ROW_MARK_SHARE
ou
ROW_MARK_KEYSHARE
en fonction de la force
du verrouillage demandé. (Le code du serveur principal agira
de la même manière indépendamment de l'option choisie parmi
ces quatre options.) Ailleurs, vous pouvez détecter si une
table distante a été verrouillée par ce type de commandes en
utilisant la fonction get_plan_rowmark
lors de
la planification ou la fonction ExecFindRowMark
lors de l'exécution ; vous devez vérifier non seulement si une
structure rowmark non nulle est renvoyée, mais également que
son champ strength
n'est pas égal à
LCS_NONE
.
Enfin, pour les tables distantes qui sont utilisées dans une
commande UPDATE
, DELETE
ou SELECT FOR UPDATE/SHARE
sans demande
de verrouillage de ligne, vous pouvez passer outre le choix
par défaut de copier les lignes entières dans la fonction
GetForeignRowMarkType
en sélectionnant l'option
ROW_MARK_REFERENCE
lorsqu'elle voit comme valeur
de puissance de verrouillage LCS_NONE
. Ceci aura
pour conséquence d'appeler RefetchForeignRow
avec cette valeur pour le champ markType
;
elle devrait alors récupérer à nouveau la ligne sans
prendre aucun nouveau verrouillage. (Si vous avez une fonction
GetForeignRowMarkType
mais ne souhaitez
pas récupérer à nouveau des lignes non verrouillées,
sélectionnez l'option ROW_MARK_COPY
pour
LCS_NONE
.)
Voir les commentaires dans
src/include/nodes/lockoptions.h
,
pour RowMarkType
et dans
src/include/nodes/plannodes.h
pour PlanRowMark
, et les
commentaires pour ExecRowMark
dans
src/include/nodes/execnodes.h
pour des
informations complémentaires.