[database] 7 things a developer should know #5
Conversation
octo-topi
force-pushed
the
seven-things-a-developer-should-know-about-database
branch
from
d36b374 to
da68181
Compare
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
octo-topi
force-pushed
the
seven-things-a-developer-should-know-about-database
branch
from
3b8c29e to
5635ca6
Compare
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
|
|
||
| **TL;DR: use a pool; make sure when scaling you do not reach max_connections** | ||
|
|
||
| ### Ride safe |
There was a problem hiding this comment.
est-ce qu'il ne faudrait pas aussi dire un mot sur les droits utilisateur ? les comptes utilisés en production pour du debug pourraient avoir seulement des droits en lecture, et il devraient être nominatifs
There was a problem hiding this comment.
Je l'ai exprimé ainsi pour ne allonger l'article. As-tu une autre idée en quelques mots ?
If you can't get a read-only account
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
| The only proper way to do this is using a SQL client and call one of these methods: | ||
|
|
||
| - `pg_cancel_backend($PID)`; | ||
| - `pg_terminate_backend($PID, $TIMEOUT)`. |
There was a problem hiding this comment.
expliquer la différence entre les 2 méthodes, et ajouter un lien vers la doc
There was a problem hiding this comment.
Je vais supprimer pg_cancel_backend et ajouter un exemple, comme ça plus de complexité.
There was a problem hiding this comment.
Ah mais en fait, ils ne font pas du tout la même chose - et la doc n'est pas claire .. Je vais expliciter ça
https://stackoverflow.com/questions/18866865/difference-between-terminating-and-cancelling-a-process
octo-topi
force-pushed
the
seven-things-a-developer-should-know-about-database
branch
from
36b6b1d to
3346308
Compare
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
|
|
||
| You may think concurrency is a concern for programming langage designers or architects, something you shouldn't worry about, something that has been taken care of at the beginning of the project. Especially in database. Well, if you want to ride full throttle, beware of concurrency. | ||
|
|
||
| Let's consider the worst case: we deploy a REST API back-end on a PaaS which offers horizontal auto-scaling, plus DBaS. If we want to max out the database performance, we should consider 2 levels : inside the database, and outside the database. You want a small pool, saturated with threads waiting for connections. |
There was a problem hiding this comment.
| Let's consider the worst case: we deploy a REST API back-end on a PaaS which offers horizontal auto-scaling, plus DBaS. If we want to max out the database performance, we should consider 2 levels : inside the database, and outside the database. You want a small pool, saturated with threads waiting for connections. | |
| 2 levels: |
There was a problem hiding this comment.
je ne suis pas sûre de comprendre pourquoi c'est le pire des cas possibles où en tout cas le ou les éléments décrits qui en font un cas compliqué
There was a problem hiding this comment.
J'ai explicité tout ça, ça valait le coup !
Peux-tu me dire si c'est compréhensible maintenant ?
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
|
|
||
| Well, to find who's not releasing the lock, [pg_locks] native view is the way to go. As it's not human friendly, and list a lock per row, use [this version](https://wiki.postgresql.org/wiki/Lock_dependency_information#Recursive_View_of_Blocking) which displays the lock tree. | ||
|
|
||
| Here, session 3 is blocked by session 2, itself blocked by session 1. The root blocking session, session 1, stays on the first line, and each indent shows the session it blocks, session 2. The lock held by session 1 is on `foo` table has not been released, because the session 1 is waiting for lock on `bar` table to be granted. Now it's your job to know this lock has not been granted. |
There was a problem hiding this comment.
un espace en trop après la virgule avant stays session 1, stays
le Here fait référence au lien sur le wiki postresql cité juste avant ?
There was a problem hiding this comment.
J'ai corrigé l'espace. En fait, il manque une image, bien vu !
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
database/7-things-a-developer-should-know-(about-database)/post.md
Outdated
Show resolved
Hide resolved
Problem
Most of web developer use a database behind their REST API, but when a problem happens, they're helpless because some concerns have not been properly address before going into production.
Solution
Provide a handful of down-to-earth, clear advice on how to monitor the database and client-side pools.
Remarks
The title is a reference to 97 things a developer should know