From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christophe Pettus <xof(at)thebuild(dot)com> |
Cc: | Wizard Brony <wizardbrony(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: CREATE DATABASE command concurrency |
Date: | 2024-09-18 14:51:22 |
Message-ID: | 1811800.1726671082@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Christophe Pettus <xof(at)thebuild(dot)com> writes:
>> On Sep 17, 2024, at 14:52, Wizard Brony <wizardbrony(at)gmail(dot)com> wrote:
>> What are the concurrency guarantees of the CREATE DATABASE command? For example, is the CREATE DATABASE command safe to be 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 be relied upon that one will succeed (unless it fails for some other reason, like lacking permissions), and the other will receive 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
From | Date | Subject | |
---|---|---|---|
Next Message | veem v | 2024-09-18 20:31:39 | Re: IO related waits |
Previous Message | Adrian Klaver | 2024-09-18 14:50:26 | Re: load fom csv |