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 1uj4UY-002Sjk-Ey for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Aug 2025 23:21:18 +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 1uj4UX-006CmA-Dw for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Aug 2025 23:21:17 +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 1uj4UX-006Clx-4O for pgsql-hackers@lists.postgresql.org; Mon, 04 Aug 2025 23:21:17 +0000 Received: from mail-vk1-xa2a.google.com ([2607:f8b0:4864:20::a2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uj4UU-000lRv-1k for pgsql-hackers@lists.postgresql.org; Mon, 04 Aug 2025 23:21:16 +0000 Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-53921f6e23bso3239105e0c.1 for ; Mon, 04 Aug 2025 16:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754349675; x=1754954475; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=X2YSMwampLHRMiNxRCHE+uii9DYzQ3eG0QK88Pm1Z20=; b=TOE5zIFikmkEAqPr1kRB4kY+SjhryOF71HLA+/E33q/IK/nUYdw/ZGATKWluGkhZmP VlOEi9w30xlG5DFbngdRL3gIKbTYdP/m8aCAuu1CRKSxPVTPOdn4/vQYI0x5q3ZAB/XL uUzSj/ZzRWuVTRSQpNuQ4VplpEWclTeTptXzyDEApYNzzc0rNhsvpJJANcO2I5LaAonR dDw5cdLTsZrPjbaSNaLWjE9rFnYp+Kv/yevytuqkB+J2jrgDfONXjr23MB455Ts8yc1V dQXi7yn32B1JsgP7xbKUL6DnPYakUBfeOri9kPoZdwmjjXOAKTo8VpxAtkvVWmh452QU 0Oaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754349675; x=1754954475; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X2YSMwampLHRMiNxRCHE+uii9DYzQ3eG0QK88Pm1Z20=; b=McZMm0jFMUa2ZliJaexXEAbQ2ngMHM07JqkzWsKPSSNMlkzMBriRpnZtb56zTgtib6 BQHalrX6AHXgJmxE3KwQIneqpDTdw5aTYO02SEyWjJWOqYkSQIbypqtGuiRrjKyN2Lug mRrNgzBLGmr9jd7My4FWdYyDTNk4sR1Cj3fR9pfrYFrW1kUP++jSckY2zjVHh2hz9+LT abIBuKkdandTuQ9SaQe78XkVR9LqZ9eAQ4H2IbxGp4ipT3orkrw1uWaL4P32yhSSxwca epIW35YJR5YJMiu3BX8xP7+PPyPWdI3KnLwEsebtgg9yPHXNcwPUj7SizGk2OY0OESA9 eJew== X-Forwarded-Encrypted: i=1; AJvYcCVlNhHR9RrWHHf2KdK0M6Xf6DXGLydVDZMnmxAcO87e5eC2Sf3Rkbd2T2Sg84xj7KwVCl40nYhzs6d1MI5A@lists.postgresql.org X-Gm-Message-State: AOJu0YzN9wDmq8l0gh9ajXjrv7Zh/M5meutDIRRBgEcU6a88VxI0J1D0 /KQAdNfCLEosTXWxGdUgLFDaHSfOwtxq3nvPHmFH4D4oBepLOC5tjVcxSmoKgDUAy6kc4Pik0ZP Rz4iOBWDq4JFDZc1dqmHRFnjbdtzj8dg= X-Gm-Gg: ASbGncv/9qskfWAplfnXs009eAWUnc41x1iP8QU6kAzh23wMNPQa/DtwFGBtdA/4gLT 77YD+URNkODt7GgFDMeaKyykS0IlP9HbrhE/+D/9V1DlvqwYbEX8dxey2V2hXDadGNTqWGU+6+M F6t1Onc/49lJqKN0P/CuSbjpsbeSnfPNYjMUK3Yj5SrqdGgXsdMlIWgrYpRgmgmZWsnAoc3QqZ5 ZpAqGcn1h/sb46xCw== X-Google-Smtp-Source: AGHT+IFteCdJ09hnCm6yfJweFmx5XXy/Dr/rq4WbYwWvS8H6jIcYB0k39QQqKNO9ur6WQNAaPGkDm9cLS0qHihkghC0= X-Received: by 2002:a05:6122:3119:b0:539:3403:7353 with SMTP id 71dfb90a1353d-5395f35fd82mr4790139e0c.10.1754349674688; Mon, 04 Aug 2025 16:21:14 -0700 (PDT) MIME-Version: 1.0 References: <202507311650.3a44mqyi3xnw@alvherre.pgsql> In-Reply-To: From: Mihail Nikalayeu Date: Tue, 5 Aug 2025 01:21:00 +0200 X-Gm-Features: Ac12FXz4RovOlLIYr4ar-PxcmfGWS3LIdc_lVz0PWac-mBvaluJJA9b8U22AbRg Message-ID: Subject: Re: Adding REPACK [concurrently] To: Fujii Masao Cc: Alvaro Herrera , Robert Treat , Pg Hackers , Antonin Houska Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello =C3=81lvaro, Should we skip non-ready indexes in build_new_indexes? Also, in the current implementation, concurrent mode is marked as non-MVCC safe. From my point of view, this is a significant limitation for practical use. Should we consider an option to exchange non-MVCC issues to short exclusive lock of ProcArrayLock + cancellation of some transactions with older xmin? Best regards, Mikhail