mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-10 09:23:24 +02:00
ac23b711dd
We should set MyProc->databaseId after acquiring the per-database lock, not beforehand. The old way risked deadlock against processes trying to copy or delete the target database, since they would first acquire the lock and then wait for processes with matching databaseId to exit; that left a window wherein an incoming process could set its databaseId and then block on the lock, while the other process had the lock and waited in vain for the incoming process to exit. CountOtherDBBackends() would time out and fail after 5 seconds, so this just resulted in an unexpected failure not a permanent lockup, but it's still annoying when it happens. A real-world example of a use-case is that short-duration connections to a template database should not cause CREATE DATABASE to fail. Doing it in the other order should be fine since the contract has always been that processes searching the ProcArray for a database ID must hold the relevant per-database lock while searching. Thus, this actually removes the former race condition that required an assumption that storing to MyProc->databaseId is atomic. It's been like this for a long time, so back-patch to all active branches. |
||
|---|---|---|
| .. | ||
| adt | ||
| cache | ||
| error | ||
| fmgr | ||
| hash | ||
| init | ||
| mb | ||
| misc | ||
| mmgr | ||
| resowner | ||
| sort | ||
| time | ||
| .gitignore | ||
| errcodes.txt | ||
| Gen_dummy_probes.sed | ||
| Gen_fmgrtab.pl | ||
| generate-errcodes.pl | ||
| Makefile | ||
| probes.d | ||