Thread: CREATE DATABASE command concurrency

What are the concurrency guarantees of the CREATE DATABASE command? For example, is the CREATE DATABASE command safe to
becalled concurrently such that one command succeeds and the other reliably fails without corruption? 

> On Sep 17, 2024, at 14:52, Wizard Brony <wizardbrony@gmail.com> wrote:
>
> What are the concurrency guarantees of the CREATE DATABASE command? For example, is the CREATE DATABASE command safe
tobe called concurrently such that one command succeeds and the other reliably fails without corruption? 

The concern is that two different sessions issue a CREATE DATABASE command using the same name?  In that case, it can
berelied upon that one will succeed (unless it fails for some other reason, like lacking permissions), and the other
willreceive an error that the database already exists. 

Christophe Pettus <xof@thebuild.com> writes:
>> On Sep 17, 2024, at 14:52, Wizard Brony <wizardbrony@gmail.com> wrote:
>> What are the concurrency guarantees of the CREATE DATABASE command? For example, is the CREATE DATABASE command safe
tobe called concurrently such that one command succeeds and the other reliably fails without corruption? 

> The concern is that two different sessions issue a CREATE DATABASE command using the same name?  In that case, it can
berelied upon that one will succeed (unless it fails for some other reason, like lacking permissions), and the other
willreceive an error that the database already exists. 

This is true, but it's possibly worth noting that the specific error
message you get could vary.  Normally it'd be something like

regression=# create database postgres;
ERROR:  database "postgres" already exists

but in a race condition it might look more like "duplicate key value
violates unique constraint".  In the end we rely on the system
catalogs' unique indexes to detect and prevent race conditions of
this sort.

            regards, tom lane