Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlkRC-004Bqk-2w for pgsql-docs@arkaria.postgresql.org; Thu, 28 Sep 2023 06:23:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlkR9-009Un7-OT for pgsql-docs@arkaria.postgresql.org; Thu, 28 Sep 2023 06:23:48 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlkR9-009Umf-Bc for pgsql-docs@lists.postgresql.org; Thu, 28 Sep 2023 06:23:47 +0000 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qlkR4-0074B7-Ce for pgsql-docs@lists.postgresql.org; Thu, 28 Sep 2023 06:23:46 +0000 Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-40566f8a093so94968345e9.3 for ; Wed, 27 Sep 2023 23:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1695882220; x=1696487020; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=qzIssi/3aMyRo7lFlEPVEYPkZyNjYWjne2YaZgus3NU=; b=uTc5xgPqNr1a+wfM1Vthy9KLyraP5JPXExECBvlL+27h7k48t6/AVXKQ2aiFZUjEvb 0jMqaW5MWmotqchCW0unxNAbIPPSuzuVI+yeVk7tgAWsAW0unBrn/uizh0M/LFiHwKLO qzsknVHoUaYxThmb4lG1UTi5Xzh1f4O8HBtz+7Qp0ukB+IpUvZqgjea0cHvwl0mlBaKe yxndAX5/VbRBWngwEQifEM2TJ9a3SfEqpblDGk/XgE3CaMXKvkzr8eFP6Z4lwuMQDoq/ bT4MucRWTfvmMyVl9TSxFFgdfKaTbdwiQvMON3JxGx0I/GHu3zFHhkA/pf3CjbBs45hs iYjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695882220; x=1696487020; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qzIssi/3aMyRo7lFlEPVEYPkZyNjYWjne2YaZgus3NU=; b=QCw8wYXRCsoFyOAPFdbsHXyw0f+UFOPjBakxMeSshr+YDj1XFsvcV0/rNc6u0aFKlt BQWzQxsZgIwY7HnNHYtyu705E2pgqMaDLPASQ4DrVOhZVNDJm0u2DieH4s9oLdiLbh8i aZzxaHaOAQ68PfUBaMdsDJYddlm2B5b7TzlapRgmvDbFeELlBTjJ4khPTP7V5CyBCFDP gp5WbTgcspkmz5rvzRej2grqmOQf6O1tWGqzilcP5/i3N4uUw5rGGELM4EaEAYv68utk gJZk70XlAl7FU/rYik421w3ZsFYxW0ZNIrLJC04TYE8XpuEsLeqSvbJ1Cqb8z6VwV1c4 kYmg== X-Gm-Message-State: AOJu0Yy9oVNRjGb3UV3p8Bp7dYDhHx86hKfgXPxqd4JZFPeZMI+sB/uD sZOyN0B7OfRpIKWLCtpADrHOPA== X-Google-Smtp-Source: AGHT+IFdwXGqIiZh2dJ+kDNhvlOI9ohsRwnVVC3YF7Pg704ABfle3BJwO1iQJCnW8ZKbKW4T4gYPzg== X-Received: by 2002:adf:f14e:0:b0:324:8239:2873 with SMTP id y14-20020adff14e000000b0032482392873mr268894wro.37.1695882219837; Wed, 27 Sep 2023 23:23:39 -0700 (PDT) Received: from localhost.localdomain ([41.66.96.86]) by smtp.gmail.com with ESMTPSA id bg10-20020a05600c3c8a00b00405323d47fdsm19644604wmb.21.2023.09.27.23.23.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Sep 2023 23:23:39 -0700 (PDT) Message-ID: Subject: Re: Is CREATE INDEX dependent on the session? From: Laurenz Albe To: Ilya Priven , pgsql-docs@lists.postgresql.org Date: Thu, 28 Sep 2023 08:23:35 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2023-09-27 at 11:23 -0400, Ilya Priven wrote: > Would it warrant a clarification in the documentation: > - Whether CREATE INDEX is aborted if the session is disconnected, assumin= g it's not in a transaction? It is aborted as soon as the server realizes that the client is gone, which= may take a while (see the keepalive parameters and "client_connection_check_int= erval"). > - Ditto for CREATE INDEX CONCURRENTLY? The answer is the same. Note that if CREATE INDEX CONCURRENTLY is interrupted, you are left with an INVALID index that you have to delete later. > - Whether CREATE INDEX CONCURRENTLY "returns" immediately or blocks the s= ession until it's created? It blocks until the index has been created. Do you want to propose a patch? Yours, Laurenz Albe