Postgres ShareRowExclusiveLock lock

Question

J'ai un serveur posgres de chargement avec une grande quantité d'opérations de mise à jour. Dans postgres.conf, j'ai défini deadlock_timeout = 8s.

Dans le journal, je vois ce qui suit:

processus

3588 acquis ShareRowExclusiveLock sur la relation 17360 de la base de données 16392 après 8000,000 ms

Cela semble vraiment lent. Quelle est ton opinion à ce propos? Y a-t-il une meilleure valeur pour deadlock_timeout? Quels autres paramètres peuvent aider à réduire les temps de verrouillage? Et cette ligne du journal indique que la transaction a été cassée et qu'aucune donnée n'a été mise à jour?

Merci pour votre aide!

Artem

Answer 1

ShareRowExclusiveLes verrous sont acquis lorsque vous avez explicitement émis une instruction LOCK TABLE. Le comportement par défaut pour LOCK TABLE est de demander un accès exclusif à la table: personne ne pourra en lire jusqu'à ce que le verrou soit libéré.

PostgreSQL utilise le contrôle de simultanéité multi-versions pour gérer l'intégrité transactionnelle dans la base de données. À moins que vous ne voyiez des problèmes d'application, je suggère de désactiver votre utilisation explicite de LOCK TABLE ou d'essayer d'exécuter votre opération de mise à jour en bloc après plusieurs heures.

Je suggère également de consulter la documentation Explicit Locks si vous avez besoin de prendre des verrous explicites.

Answer 2

Avez-vous lu ceci?

http://www.postgresql.org/docs/current/static/runtime-config-locks.html

Idéalement, le réglage doit dépasser votre temps typique d'une transaction afin d'améliorer les chances qu'un verrou soit relâché avant que le serveur décide de vérifier l'impasse.