Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kQbs7-0007Mk-2A for pgsql-sql@arkaria.postgresql.org; Thu, 08 Oct 2020 19:46:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kQbs4-00015A-K5 for pgsql-sql@arkaria.postgresql.org; Thu, 08 Oct 2020 19:46:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kQbs4-000153-CJ for pgsql-sql@lists.postgresql.org; Thu, 08 Oct 2020 19:46:36 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kQbs1-0000sg-Md for pgsql-sql@lists.postgresql.org; Thu, 08 Oct 2020 19:46:36 +0000 Received: by mail-pf1-x432.google.com with SMTP id l126so4843659pfd.5 for ; Thu, 08 Oct 2020 12:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:user-agent:mime-version :content-transfer-encoding; bh=7v5fdt01hhJ953XWHC0vrqbupL5NcXSZ1yTU5xcL/0w=; b=TFhfSTiykiF+uhFMH+Pcd/5eLVGUcAgUPBH4nS6c/t89VYJ1Niln1dB8GqO/1w0WE6 lFHTLxLVzFnV3F0AughDBdI7VWPobMTmPhSvab9q06UENBGSVnozb8dB5ig2IIbVpawk RlZBD+BXpouJm4oE3lJPKpzCaix5OwUSsDkmpQb/+E/6y7pOSTk2/1wmrW3ChbHTT29u KJ29IuS29kTLm4C9JeLykpF4BL/TfGQJZHhfbuT7BlKcTnU5UOIGllqb/sPQPbA2Odjs UnPD8IozXDLt5GBds7iD1mQm/LVa8mI9BDRrL2PoArMiKss9fHmPBSO4gINBPfqYrWsR A08w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:user-agent :mime-version:content-transfer-encoding; bh=7v5fdt01hhJ953XWHC0vrqbupL5NcXSZ1yTU5xcL/0w=; b=N0rnnoxsllkses5pznQbA01S8QdSavPn71RpNONal9fxhMpSdS/dJ7mtD5uwSB+oSJ DfFinLJKxi+XSLlvnYiYchwK+OqEhTzNJGz8bN9+FVSSLqCQJXbQOg44JDz84QGHw97B v1yvT68H5WBNl69u1/OxWKPE4sJ8EGPj0INp0KO85c7du+u9lTuHiyFnrveMprJ/g6WW 3aMttUOcxiW7isQ1t2UN5JN0p3Fa06NKT2MfUKlVDXGmAK8X+ZksWrd0jZAuZNx1TMXK RreGQpkrVJLkh0I0TC8L4bMPMjRos3RjApw9CFVj0uOV9xPZxShIo3JYFLgwZnw2AjIB ojoQ== X-Gm-Message-State: AOAM530o3jQWEXOkoMdvXTaXVCRZUB3z9OobrGKM4giU8Hrf/Tqvsc1x PgZt7dTR5OUcR1SsTKrgW2y83N8rB18= X-Google-Smtp-Source: ABdhPJwBEsumFtoAzB4bOw0RS3mdW9HdFh9uW4WrlQ1bB0mn6tXI/xK4pqYiqzOGtAz54C+ktsu8Cw== X-Received: by 2002:a17:90a:4e47:: with SMTP id t7mr492684pjl.26.1602186390127; Thu, 08 Oct 2020 12:46:30 -0700 (PDT) Received: from pavlo-debian ([204.147.87.6]) by smtp.gmail.com with ESMTPSA id b5sm8181966pgi.55.2020.10.08.12.46.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2020 12:46:29 -0700 (PDT) Message-ID: <390804abe88e4e9da9049f6e05c841783acaca47.camel@gmail.com> Subject: libpq CREATE DATABASE operation from multiple treads From: p.sun.fun@gmail.com To: pgsql-sql@lists.postgresql.org Date: Thu, 08 Oct 2020 14:46:24 -0500 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, PostgreSQL community. I hope everyone is doing great and keep themselves safe and healthy. I am not sure whether my question should belong here. Please advise if this is the wrong place. I am contributing to the libgda project ( https://gitlab.gnome.org/GNOME/libgda) which a convenient wrapper around multiple SQL providers. We have good support for PostgreSQL and would like to keep so in the future. To test our code we use CI+Docker. Docker provides SQL server functionality. Everything is fine but... We have an API to run DDL operations. Everything works ok but once in a while, we have a problem to create a new database if we run multiple build processes communicating to the same SQL server. In our code, the process to create a new database consist of the following steps: 1) Connect to "template1" database 2) Execute "CREATE DATABASE " 3) Close connection 4) Open a connection to the new database. I was trying to explore this problem using libpq to better understand the origin of the problem. This is a test code: void function_to_run_in_a_thread(void *data) { /* The passed void *data is a pointer to an SQL string with a randomly generated database name, e.g. CREATE DATABASE kajdygsj */ const char *sql_create_db = (const char *)data; const char *cnc_string = "host='localhost' user='test' password='test1' dbname='template1'"; PGconn *cnc = NULL; PGresult *res = NULL; cnc = PQconnectdb(cnc_string); if (PQstatus(cnc) != CONNECTION_OK) abort(); res = PQexec(cnc, sql_create_db); if (PQresultStatus(res) != PGRES_COMMAND_OK) abort(); PQclear(res); PQfinish(cnc); } I run this function using only one thread and everything works great. If I use two threads, the PQresultStatus(res) != PGRES_COMMAND_OK. I was trying to add a delay time for PQresultStatus(res) != PGRES_COMMAND_OK and repeat the same command but didn't help much. If I drop connection for PQresultStatus(res) != PGRES_COMMAND_OK and open it again after some random delay, it works. Can the server handle CREATE DATABASE requests in parallel? Thanks, -Pavlo