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 1vT2pL-00Bp1Z-2q for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Dec 2025 18:52:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vT2pK-00696U-16 for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Dec 2025 18:52:46 +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.96) (envelope-from ) id 1vT2pJ-00696L-2E for pgsql-hackers@lists.postgresql.org; Tue, 09 Dec 2025 18:52:46 +0000 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vT2pE-0045wM-2Z for pgsql-hackers@lists.postgresql.org; Tue, 09 Dec 2025 18:52:45 +0000 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-477b198f4bcso52330145e9.3 for ; Tue, 09 Dec 2025 10:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1765306359; x=1765911159; darn=lists.postgresql.org; h=message-id:date:mime-version:comments:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=a7Rj9YSQJNhRy+UD+hebD77w9Yg68orX6C0VqLIxFkc=; b=VCTIURd8vG3M81Uafk+rgfI6OupdonqIURMpC1A9EYMOQmw0e9XFDs3eCBWOgtW7OE 3wv9XJaiIBovgcJlTf9LT7v87JFnpcGDD+2/1vCa6s4Qb7fXA2GtNICOkjnM9i1UGwqY d5tNv0DZ7oTmOj6AiClGzwy9vaiHFV6Tp6WdmKPGCcRwzUa5Ordmyia8b7Xh0D1xOfvB fecDtB3xvgjHww/C6OWkjsj5ok1h1dZIaZVxNbjY02RTFgEyPA6nfHp68+E6Z26EnD4R dAxzRmrKQVe1DoBnNODoR8aeHPSHup5wQwGRe4ipWGT+f2Dyz+Nmib31S+9EW+maZCoT vcaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765306359; x=1765911159; h=message-id:date:mime-version:comments:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=a7Rj9YSQJNhRy+UD+hebD77w9Yg68orX6C0VqLIxFkc=; b=DygKeYV9kUBNAOaTyborC5FH3e0xwML0Spt9tjiNd2FTHtn42/Scj8w7qDuPD7WA/r asUe0l2WmSdN3WqZTjrKSrJq3TsbcIsld8QDABd0OSWg3qlhb/UeXlUG8nWnIXpuvH4z LC0kSZHXwJLK9mmUkCWuhsKAn+7GhVUaJeFm5HX37VQ5z3Eya9XgHXDOqIdCE4dRNYEz 3G+jIlW/r//SFvIdCn2Bo2BTyEGl+rGrxVvM7dt5U9sIci/vfI9azAdgTZXABohSRCnN lCC+/nAaSexd9HPM5O3xshLMlGzY+9VMaFjqae6pr5MB2QsmMA/03dBuP7269vCdOwCy 9xjg== X-Forwarded-Encrypted: i=1; AJvYcCVM4mNXfSw6k0q70NwLgTRmN9TMzgE8nPp64W4KKnVEkjL9Uc45xajsiv5xamTi8zel4kbdUlSD6h8jOQxF@lists.postgresql.org X-Gm-Message-State: AOJu0YxaJHg8q484/NZqWlHKZ2BdupS3wIAVnWtQ+eOZBz+veK+ZrVwn ZXHIfX3ovbOqHm9bvudwurMHjQ3X5D32N0Q9BQhvDST7MaLyzUateVPXFS5cge029SA= X-Gm-Gg: ASbGnctvGZt7+9DfZrHHffUsdc7gK4D+UacnCJaGsMpFu2tFJeG4PWLWxzW0vzAQyJB 2ViJ9o6PPZbHHL8a2Oc3aSBi4Hx2Inl86i2LxvXqvxBypK+EgYXndLcrXrkkzEbJBHYsH+cfg0E OH4AzyiPXftzhfYqjZzPTyTYUPHZ/Tn9tEf3lQzyuWppPcUuczAPNAORC/IxM0gNryMynZmGTc/ L/y9+ms+vbF7RTTSLktxzn8w63PkuWB+eDQS1ZDueA8f1GLvN5u0isEndOW0hHrCBNjrQZ5V4Cc KjXndpuEsra5A4vSe8Vq2fr6ain6si/dqNNVpqdwxkSqhXEOnuhW6ygRdHsfaiio/J0KoKhph8d r4zB8N/5FpVlVcufp/MMG3TCBd9GGTq9Rymav4wch5TwwBastq+ekXKDosMlyM1niOpcyPEwTBP A4hzkakFLUUucik1Dq6u9ImME8 X-Google-Smtp-Source: AGHT+IEbKMpmp/tGoJzry0qOeOJDqz7uPcAKwStErzm5demU881uVpEcFVn1EskZxTjtKbd0ZrAKyQ== X-Received: by 2002:a05:600c:8b26:b0:477:7725:c16a with SMTP id 5b1f17b1804b1-47939dfa631mr123834425e9.10.1765306358958; Tue, 09 Dec 2025 10:52:38 -0800 (PST) Received: from localhost (109-81-168-246.rct.o2.cz. [109.81.168.246]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47a82d255e7sm4768865e9.4.2025.12.09.10.52.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Dec 2025 10:52:38 -0800 (PST) From: Antonin Houska To: Mihail Nikalayeu cc: Alvaro Herrera , Pg Hackers , Robert Treat Subject: Re: Adding REPACK [concurrently] In-reply-to: References: <202510301734.pj4uds3mqxx4@alvherre.pgsql> <116433.1764870207@localhost> Comments: In-reply-to Mihail Nikalayeu message dated "Sun, 07 Dec 2025 17:03:00 +0100." X-Mailer: MH-E 8.6+git; nmh 1.8; GNU Emacs 28.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Tue, 09 Dec 2025 19:52:37 +0100 Message-ID: <171530.1765306357@localhost> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --=-=-= Content-Type: text/plain Mihail Nikalayeu wrote: > 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 :) Indeed, that may be a problem. > 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) I prefer not to depend on other improvements. > Or should we move repack_decode_concurrent_changes calls into some > kind of worker instead? Worker makes more sense to me - the initial implementation is in 0005. > --- > > 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. Good point, I missed this. > And also upgrade before swap probably. rebuild_relation_finish_concurrent() already does that. > --- > > cluster_is_permitted_for_relation(RepackCommand cmd, Oid relid, Oid userid) > > Should be check CheckSlotPermissions(); here? Aso, maybe it is worth > mentioning in docs. setup_logical_decoding() does that, but I'm not sure if we should really require the REPLICATION user attribute for REPACK. I need to think about this, perhaps ACL_MAINTAIN is enough. > --- > > 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. I added test for TOAST to "injection_points" and hit a serious problem: when applying concurrent changes to the new table, REPACK tried to delete rows from the new one. The point is that the "swap TOAST by content" technique cannot be used here. Fixed, thanks for this suggestion! > > * 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. ok, changed > --- > > rebuild_relation(RepackCommand cmd, Relation OldHeap, Relation index, > > "cmd" is not used. Fixed (not specific to 0004). > --- > > apply_concurrent_update > > apply_concurrent_delete > > apply_concurrent_insert > > "change" is not used, but I think it is intentionally for the MVCC-safe case. Not sure if it's necessary for the MVCC-safe case, I consider it leftover from some previous version. Removed. > --- > > rebuild_relation(RepackCommand cmd, Relation OldHeap, Relation index, > > bool verbose, bool concurrent) > > "concurrent" is "concurrently" in definition. Fixed. > --- > > > TM_FailureData *tmfd, bool changingPart, > > bool wal_logical); > Maybe "walLogical" to keep it aligned with "changingPart"? ok > --- > > subtransacion > typo > I removed the related code. It was a workaround for plan_cluster_use_sort() not to leave locks behind. However, as REPACK (CONCURRENTLY) does not unlock the relation anymore, this is not needed as well. > --- > > Should we check a the end > > "a" is "at"? Removed when addressing one of the previous comments. > > --- > > Note that REPACK with the > > the CONCURRENTLY option does not try to order the > > double "the" Fixed. > --- > > if (size >= 0x3FFFFFFF) > if (size >= MaxAllocSize) Fixed. > --- > > extern bool HeapTupleMVCCInserted(HeapTuple htup, Snapshot snapshot, > > Buffer buffer); > > extern bool HeapTupleMVCCNotDeleted(HeapTuple htup, Snapshot snapshot, > > Buffer buffer); > > Looks like this from another patch. Right, this is from the "MVCC safety part". > --- > src/backend/utils/cache/relcache.c > > #include "commands/cluster.h" > > may be removed Yes, this belongs to some of the following patches of the series. > --- > > during any of the preceding > > phase. > > "phases" Fixed. > --- > > # Prefix the system columns with underscore as they are not allowed as column > > # names. > > Should it be removed? Done. (Belongs to the "MVCC-safety" part, where the test check xmin, xmax, ...) > --- > > "Failed to find target tuple" > > This and multiple other new error messages should start with lowercase Fixed. > --- > > Copyright (c) 2012-2024, PostgreSQL Global Development Group > > in pgoutput_repack - maybe it is time to adjust. Done. > --- > src/test/modules/injection_points/logical.conf > > Better to add newline Done. > --- > > SELECT injection_points_detach('repack-concurrently-before-lock'); > > Uses spaces, need to be tabs. ok Thanks for the review! -- Antonin Houska Web: https://www.cybertec-postgresql.com --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename=v27-0001-Add-REPACK-command.patch Content-Transfer-Encoding: quoted-printable