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 1tiomE-002dW4-BV for pgsql-general@arkaria.postgresql.org; Fri, 14 Feb 2025 06:02:14 +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 1tiomC-003ekE-4c for pgsql-general@arkaria.postgresql.org; Fri, 14 Feb 2025 06:02:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tiomB-003ejl-P2 for pgsql-general@lists.postgresql.org; Fri, 14 Feb 2025 06:02:12 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tiomA-000kco-1Q for pgsql-general@lists.postgresql.org; Fri, 14 Feb 2025 06:02:12 +0000 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-ab7f76aeedbso212807066b.3 for ; Thu, 13 Feb 2025 22:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kleczek.org; s=google; t=1739512929; x=1740117729; darn=lists.postgresql.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ClVqz6QfWxoqI2cdOUjI3NLVl76tt0iIQw3jk2emfo8=; b=OlUjdkAdUrKcTiRPeD03GCqZWAClBkqkJKoQomuVCDk985baYlmutXd6+bfQjCI69m 3PZV5F3K+2kUIxDAlBDKx6oaKhgpl3B6s4TKMuMFQJJokKVz+k80MYoj3YN4v93Vgmgf x72tRYxG4x0ng1EC0jJaiMT3iAra27XnMGGks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739512929; x=1740117729; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ClVqz6QfWxoqI2cdOUjI3NLVl76tt0iIQw3jk2emfo8=; b=u01/pYPEck2YXMRxK0zivGWoYBMybVhsrgmf9r8ShjK3O+cO1vfdk09IwAlPzFB4uV Po6G/ErxUve26yPG5VPT4x4Pvue/if+7ICwZhgjo7GkUVllCyjSM8Gddqsc98FvXIgWo g5kb5eeTKT8h7dL6o7MdmMxjkjtmnrRbOCMlxd7vmwAADkoQj4ihXE3cocgIB+5aRKTh Idh/HQpvcCkm1yzRWIl3zMxOT//wuqWwCkBjMEWEG4pddhsbK/sQIndrjd0bBXkitPLt TOOsX0xY6JUzHYAtWeTZ/QWlt0y5pniOdaAASXzliHSR8vzHU9a05EeKuUPYvHBwL2M4 in+w== X-Forwarded-Encrypted: i=1; AJvYcCWd/CgnP+Ohlyk//oeuyGcAjBOKI6oPOofcfpJ674VyIt+MSgPZEUA+2oCEgHMs8bhZPe/tAnq3NjtfMz+0@lists.postgresql.org X-Gm-Message-State: AOJu0YyVwWBNHW3mHuN8MED06141xAUAPjIbCUEBuEFuemPsnJjzseim kW1dLY45SchJZv7lbXxTfAcBnU0wrVZ2mqm525nx3Wg1AJH8j8bbtlzkunxjqQk= X-Gm-Gg: ASbGncs1IZ1xlDzDIquTOaF98bid/0geOTeJ2iBodhvCbYmkzTN0/SWEikVcXUVY22b jTn43ywWDNX+sihOCd6usgpZo2Ld0BhDPxK9aGnLjD8y3JDs9TWs95vqPowQewzNo/hZD9M74iP CcF5U+diDEJwJ89+0fBiFO/hHFOSlBEeDt/XpMvtXQCpjBuap9EZ5G6DZb69zUdTURx0NYBLQkP aBP+x5pujcbnSHDzQdKdw7939V/vEw1Dr3imv83SkB/oVZKJ2pSlgwYsr0tKtMWuV6hM9Y506yT WGOEcFdEoRVUUkoQH01eG9TQgjy7EARng26yhFOJNjc= X-Google-Smtp-Source: AGHT+IEY23qAvpbIK9iCozky8iDE+3+/+3YieB+PsUefqeufEmEoPETDznRBrnUwYolDriIU+x1LNw== X-Received: by 2002:a05:6402:5285:b0:5dc:5a51:cbfa with SMTP id 4fb4d7f45d1cf-5dec9d2c185mr16604863a12.6.1739512929100; Thu, 13 Feb 2025 22:02:09 -0800 (PST) Received: from smtpclient.apple (b15.kleczek.org. [185.20.172.182]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aba569dd320sm239465566b.72.2025.02.13.22.02.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2025 22:02:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: Best Approach for Swapping a Table with its Copy From: =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= In-Reply-To: Date: Fri, 14 Feb 2025 07:01:55 +0100 Cc: Adrian Klaver , pgsql-general@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <44BB6A74-0AB1-462C-B13A-2CF106DA70D6@kleczek.org> References: <8ac6a1dd-db82-4ea7-8186-0c354d79049f@aklaver.com> To: Marcelo Fernandes X-Mailer: Apple Mail (2.3826.400.131.1.6) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 12 Feb 2025, at 22:27, Marcelo Fernandes = wrote: >=20 > On Thu, Feb 13, 2025 at 10:02=E2=80=AFAM Adrian Klaver >=20 > Also pulling in your question in the other reply: >=20 >> Why can't you just add the exclusion constraint to the original = table? >=20 > With unique constraints, one can use a unique index to create the = constraint > concurrently. >=20 > With check constraints, one can create the constraint as invalid and = then > validate it while only requiring a share update exclusive lock. >=20 > But with exclusion constraints, neither of those techniques are = available. In > that sense, there is no way to create this type of constraint in a = large table > without copying the original table, adding the constraint, and = performing a > table swap. >=20 > This is done to avoid having to hold an exclusive lock for a long = amount of > time, thus creating application outages. >=20 Just a wild idea (not sure if anyone suggested it in this thread and not = sure if it is doable): Create index concurrently and then fiddle with the catalog tables to = define the constraint using this index? =E2=80=94 Michal