Forums PostgreSQL.fr

gglamenace

Membre

INSERT et accès concurrentiel

Bonjour,

je désire faire un insert à partir d'une procédure stockée en récupérant le dernier index de ligne de la table (champ auto incrémenté), l'incrémenter de 1 et utiliser ce nombre pour remplir un autre champ.
Si tout se passe bien POSTGRESQL fera l'insert en incrémentant de lui-meme l'index et du coup le champ calculé à partir de l'index sera cohérent.

Mon problème est que je ne suis pas certain qu'entre le moment où je récupère le dernier index et le moment où je fais l'INSERT, un autre INSERT n'aura pas déjà incrémenté l'index et donc l'INSERT que je fais dans ma procédure produira une ligne avec un index qui n'est pas celui utilisé pour remplir un autre champ.

Pouvez-vous me donner la bonne pratique pour ne pas avoir ce genre de problème?
Je ne sais pas si je peux utiliser un TRIGGER AFTER ou autre.

Si vous pouvez m'éclairer...

Merci
Jérôme

Marc Cousin

Membre

Re : INSERT et accès concurrentiel

Le mieux, en théorie, c'est de ne pas le faire: vous risquez d'avoir des problèmes de concurrence très importants (vous allez sérialiser les insertions dans cette table). Donc d'utiliser des séquences et d'accepter les trous.

Sinon, le «deuxième mieux», c'est d'avoir un enregistrement dans une table externe, qui sera verrouillé pour faire la «séquence».

Quelque chose du genre:

BEGIN;

UPDATE table_sequence SET valeur=valeur+1 where cle=cle_table_principale RETURNING valeur

INSERT INTO ma_table_principale xxxxxxxx (dont la valeur récupéréé).

COMMIT;

L'update, fait comme ça, empêche tout autre update de l'enregistrement tant que votre opération à vous n'a pas réussi ou échoué. Évidemment, si vous avez un gros traitement entre l'update sur la table de séquence et le commit, pendant ce temps là, personne d'autre ne peut faire d'update. C'est pour ça que dans la mesure du possible, on accepte d'avoir des séquences «à trou» (sauf pour des factures ou autre besoin fonctionnel de ce genre, où c'est une obligation de ne pas avoir de trou).

---

Marc.

gleu

Administrateur

Re : INSERT et accès concurrentiel

Utilisez une séquence, c'est fait pour ça. Voir http://docs.postgresql.fr/9.1/sql-createsequence.html pour les détails.

---

Guillaume.

gglamenace

Membre

Re : INSERT et accès concurrentiel

Utilisez une séquence, c'est fait pour ça. Voir http://docs.postgresql.fr/9.1/sql-createsequence.html pour les détails.

Bonjour,

j'avais pensé utiliser les sequences pour que ce soit POSTGRESQL qui me fournisse la valeur calculée en automatique, mais avec les sequences on ne peut générer que des nombres.
Dans mon cas je veux remplir un champ en convertissant l'index de la ligne en base64.
J'ai trouvé ceci comme doc pour utiliser du PL/SQL en tant que trigger:
http://www.postgresql.org/docs/9.1/inte … igger.html

Je pense que le trigger AFTER INSERT et l'utilisation de l'objet NEW pour avoir récupérer la valeur de l'index et pouvoir faire un update du champ dans lequel je stocke en base64 l'index me permettra de garder la cohérence entre l'index et le champ contenant l'index en base64.

Ca fait malheureusement un INSERT puis un UPDATE, mais je ne vois pas d'autre solution.

Qu'en pensez-vous?

Jérôme

gleu

Administrateur

Re : INSERT et accès concurrentiel

Le problème que vous allez rapidement rencontré, c'est que votre trigger ne fonctionnera pas si vous ne verrouillez pas en écriture la table le temps de faire votre insertion. Et là, les performances vont devenir ridicules.

Le mieux serait d'expliquer pourquoi vous ne pouvez pas passer par une séquence, histoire de trouver une solution passant par une séquence

---

Guillaume.

gglamenace

Membre

Re : INSERT et accès concurrentiel

J'ai une table avec 3 champs:
index (entier auto incrémenté)
index_base64 varchar(10)
URL varchar(200)
je voudrais à chaque INSERT que le champ index soit auto incrémenté par POSTGRESQL, que je remplisse le champ URL et que le champ index_base64 soit calculé en prenant index et en le transposant en base64.

Quelle serait selon vous la meilleur solution?

Merci d'avance pour votre aide.

Jérôme

Dernière modification par gglamenace (02/07/2012 23:26:02)

gglamenace

Membre

Re : INSERT et accès concurrentiel

J'ai aussi pensé à utilisé now pour le champ index qui me donne date et heure avec les microsecondes et utiliser la date/heure et le convertir en base64.
Qu'en pensez-vous?

Dernière modification par gglamenace (02/07/2012 23:46:01)

gleu

Administrateur

Re : INSERT et accès concurrentiel

Le champ index étant un entier, une séquence me paraît la meilleure solution.

Quant à now(), je ne vois pas en quoi cela change le problème. Il existe toujours une possibilité que vous ayez deux mêmes dates et heures.

---

Guillaume.

flo

Membre

Re : INSERT et accès concurrentiel

Personnellement, je pense que tout cela est bien compliqué et surtout je ne comprends absolument pas votre besoin de "convertir" l'index en base64, et de le stocker. Si l'index_base64 est calculé à partir de l'index, il vaut mieux ne pas stocker les 2 (vous n'êtes pas en première forme normale dans ce cas...)
Pourriez-vous expliquer ce que vous voulez faire réellement? À quoi sert tout ce micmac?

gglamenace

Membre

Re : INSERT et accès concurrentiel

Merci pour vos réponses,
je vais effectivement ne pas stocker la valeur en base64 et la calculer à la voler!

Personnellement, je pense que tout cela est bien compliqué et surtout je ne comprends absolument pas votre besoin de "convertir" l'index en base64, et de le stocker. Si l'index_base64 est calculé à partir de l'index, il vaut mieux ne pas stocker les 2 (vous n'êtes pas en première forme normale dans ce cas...)
Pourriez-vous expliquer ce que vous voulez faire réellement? À quoi sert tout ce micmac?