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.96) (envelope-from ) id 1vSHF2-00AQs9-2d for pgsql-hackers@arkaria.postgresql.org; Sun, 07 Dec 2025 16:04:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vSHF1-00Dbu8-0U for pgsql-hackers@arkaria.postgresql.org; Sun, 07 Dec 2025 16:04:07 +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.96) (envelope-from ) id 1vSHF0-00Dbtz-2b for pgsql-hackers@lists.postgresql.org; Sun, 07 Dec 2025 16:04:07 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vSHEy-003cB4-1U for pgsql-hackers@lists.postgresql.org; Sun, 07 Dec 2025 16:04:06 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5959105629bso3779367e87.2 for ; Sun, 07 Dec 2025 08:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765123442; x=1765728242; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cjSxkVCi0Nmka5eiVjLImMNWacntAajrWYe7PMxgibA=; b=BwYfDCuUdxLVwZYliBi3lI4SR3Dg+hldxb6zhF9s4kwf9MsNXDpgRFYZaXix5M8qMD +XHabvvgPuKcDBr4eIEZpiVa3sPivj6rCC7oj1JVWRCgD4PsNjf2pUk8oS7EkkK+jRD8 9TbzZli0OeIX1YLiU0j0bq9BCfA6X3A3F5gwXkizSodjlNw4J9oeP3Z2tLc3+EwX+Yvi CvTGk0NmGaNqN1q1kWEjD/YvWyMYDlCxks1nmO2uLLz+cGq6SSaVUlyvGYrQiSELBPF9 nDQ0WNb7LLOzqf2hzAEAvFm+caPCNBnyTackbwuh3pbR/6fvt6MaOOLT9FLOdVbL7xdX zIRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765123442; x=1765728242; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cjSxkVCi0Nmka5eiVjLImMNWacntAajrWYe7PMxgibA=; b=BMfgzWh7Q62uujin54cGkMKZucSklpMvd3hk+QoDih//du2oEdKSb7k2mh55GAzvf5 6J/hJ/uiaRuIukIzs4Id/t6CJO5CbxPzwXX+q7zrLMl3+CBLxUh6hLaQASm88T0jIkve 89bXYo5QLdlDwJ+oM/XQsFPLviwW8uUl2+LeJ7vwSeBTBXuD+64OIijUj+QUnM5RvVgo WmHBco4oMf8R41SgrpCfAGwzsOXjX4ZBgl0I6Ti4cFvnemmvBtVkIaVTWSMx70Lnqu4I w//na+o9lcb/4UPBiyjTnlYA/uTQDtRbCj9Dw7G4eXAsAfpjL8d+vuLOtYgt5XWMWVwp +GfQ== X-Forwarded-Encrypted: i=1; AJvYcCUJjKrxrDlgTgPfHNUCw0a5BdOXTzecK+dZGCvpbiVjGRVvzoruBI53pO7Ril9cRoH38lmNflBSOERuy7+9@lists.postgresql.org X-Gm-Message-State: AOJu0YxD9XoWw8FNmY9Q9rEj04H1YQkbE7rY+PXuIt8xxuvSyOML+s+v J15JWZPPHUnFyqBxusBo4j4wdmpDi0M6U89hJf5l6ZAdeVthgFny6/yfp00mi452tRtLjaJVMdC gpM0EIEo8gpCz5dNUH05OjZW7BJhDT8w= X-Gm-Gg: ASbGncuPhUJcPSB0yZfpLHWcM2OiDfn3za5Zigi26tZDD5E2aghZstNqTXf0AJ2a5Dl mq88B2UqUKwdDco3CFD5UVpjfRH0IdkpMBjiQz/vk8V9vyAaHPhQ+PzvB383/ixEVyfMGZNKbpp f7TDH96idvNe85lz1aiSxa7rdK2voUkAjEeH+30rqJ3uL0D0rR1L7l30W5zMPnbRRXQreGx7wxh sGPWh7r4lOblWKZCFDdh0ORUYFCfQvWBbz6MPuPkQWIV077yD2n0LzMhxzZyHvfI07UHeI= X-Google-Smtp-Source: AGHT+IEiVu6z3KhE4o7wfy0AEQWmz6rTPUdekR5BRD1erN1YDpCYyVc5UwJKN1t8cpq5LPf5gLn5EAKqdUkXSK4jWLE= X-Received: by 2002:a05:6512:3e0e:b0:597:d702:58e5 with SMTP id 2adb3069b0e04-5987e8de6b7mr1817365e87.39.1765123441839; Sun, 07 Dec 2025 08:04:01 -0800 (PST) MIME-Version: 1.0 References: <202510301734.pj4uds3mqxx4@alvherre.pgsql> <116433.1764870207@localhost> In-Reply-To: From: Mihail Nikalayeu Date: Sun, 7 Dec 2025 17:03:00 +0100 X-Gm-Features: AQt7F2r0WN8ujvzERpM1RUJHLeEav1hOF-0x3YVopB2cfAMuvIF_uQSV2dK3cbU Message-ID: Subject: Re: Adding REPACK [concurrently] To: Antonin Houska Cc: Alvaro Herrera , Pg Hackers , Robert Treat Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, comments so far on 0004: --- > ind_oids_new = build_new_indexes(NewHeap, OldHeap, ind_oids_old); I think the biggest issue we have so far - repack_decode_concurrent_changes is not called while new indexes are built (the build itself creates a huge amount of WAL and takes days sometimes). Looks like a way to catastrophic scenarios :) Some small parts of it may be related to reset snapshots tech in CIC case: 1) if we build new indexes concurrently in REPACK case 2) and reset snapshots every so often 3) we may use the same callback to also process WAL every so often 4) but it still not applies to some phases of index building (batch insertion phase, for example) Or should we move repack_decode_concurrent_changes calls into some kind of worker instead? --- > if (OldHeap->rd_rel->reltoastrelid) > LockRelationOid(OldHeap->rd_rel->reltoastrelid, AccessExclusiveLock); I think we should pass mode from rebuild_relation here - because AccessExclusiveLock will break "CONCURRENTLY" totally. And also upgrade before swap probably. --- > cluster_is_permitted_for_relation(RepackCommand cmd, Oid relid, Oid userid) Should be check CheckSlotPermissions(); here? Aso, maybe it is worth mentioning in docs. --- > REPACK (CONCURRENTLY) repack_test USING INDEX repack_test_pkey; Some paths (without index) are not covered in any way in tests at the moment. Also, I think some TOAST-related scenarios too. > * Alternatively, we can lock all the indexes now in a mode that blocks > * all the ALTER INDEX commands (ShareUpdateExclusiveLock ?), and keep I think it's better to lock. --- > rebuild_relation(RepackCommand cmd, Relation OldHeap, Relation index, "cmd" is not used. --- > apply_concurrent_update > apply_concurrent_delete > apply_concurrent_insert "change" is not used, but I think it is intentionally for the MVCC-safe case. --- > rebuild_relation(RepackCommand cmd, Relation OldHeap, Relation index, > bool verbose, bool concurrent) "concurrent" is "concurrently" in definition. --- > TM_FailureData *tmfd, bool changingPart, > bool wal_logical); Maybe "walLogical" to keep it aligned with "changingPart"? --- > subtransacion typo --- > Should we check a the end "a" is "at"? --- > Note that REPACK with the > the CONCURRENTLY option does not try to order the double "the" --- > if (size >= 0x3FFFFFFF) if (size >= MaxAllocSize) --- > extern bool HeapTupleMVCCInserted(HeapTuple htup, Snapshot snapshot, > Buffer buffer); > extern bool HeapTupleMVCCNotDeleted(HeapTuple htup, Snapshot snapshot, > Buffer buffer); Looks like this from another patch. --- src/backend/utils/cache/relcache.c > #include "commands/cluster.h" may be removed --- > during any of the preceding > phase. "phases" --- > # Prefix the system columns with underscore as they are not allowed as column > # names. Should it be removed? --- > "Failed to find target tuple" This and multiple other new error messages should start with lowercase --- > Copyright (c) 2012-2024, PostgreSQL Global Development Group in pgoutput_repack - maybe it is time to adjust. --- src/test/modules/injection_points/logical.conf Better to add newline --- > SELECT injection_points_detach('repack-concurrently-before-lock'); Uses spaces, need to be tabs. Next step in my plan - rebase MVCC-safe commit and test it with some amount of stress tests. Best regards, Mikhail.