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 1w85mx-000CnK-1G for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2026 00:19:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w85mw-00342n-0c for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2026 00:19:58 +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 1w85mv-00342f-2s for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2026 00:19:58 +0000 Received: from mail-vk1-xa2a.google.com ([2607:f8b0:4864:20::a2a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w85mt-000000006Ro-1POF for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2026 00:19:58 +0000 Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-56d8d479149so143130e0c.2 for ; Wed, 01 Apr 2026 17:19:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775089194; cv=none; d=google.com; s=arc-20240605; b=Mg1XD39NnnvLdeyalWqbketvr8YAoWFwfvEPBBgK1RuMJ8x5AIIX6+n2A5XTJYDSOc 3gCTNI++Vo1xZ2NbRHhtu1j2TS70rAcmwK6f7MaDRRAVJ676KoR/7Nc9kd/6B8/i4XQE Cc0XDodjOaZM9o3LXAx2yY4ByPRgKyOgPbhbyhcaVLpt6CQej88yDvTJe0BTZDmfQUhS NfKJHeQNgayoeG1RJb6GAA6D0x1t4txGbgMJTU4y+BnhAaoP8RM04eFYRYE+3eMWHcCb qus/6eDed2PrCzpPC20LAyeJcE2uHVQ8Z8Etc3pSJovdPw1yxRfgLxmpIUmlG6mgh0Ux dFrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=vKJ9BzA17XZF30KI9Dquw4SM4Piod0c/OdDbWoR4r48=; fh=Aa2aNX76WNRXZP4xmfLeyrBe+7DRT1ez6sEobOyNP98=; b=gT2cc+OCEMR/Xpfn/ME0OnehNJvtpYLpygD8HDBhEEaWTSiRiaEf/0EFRNsvc/Myog iu8vQZWJCTTLG7uGBY+AU/OwmDZjla3JjwU7fg7tD4oZeq2Hrz+NqsWCR1ydksq0nWYR udW1ESaJIzR3UGvUb9X2hgBiop1feMCxQYx2vBhRlGggSuQRXTDGCIl4gbMg3A/bM5t6 THcI/B1hi2qIY/KGnQeY77ZH5W7s8NmdS517+gGAET/2UwoilB4eVNcQ1rwT1sbxGYLm DpJOpTHpysbBHBLZuBGs6ecAjnKp0amQG1lmuYi9cWn1/YB/tfX4CcZhPMEkZvpj5QVq iQMQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775089194; x=1775693994; 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=vKJ9BzA17XZF30KI9Dquw4SM4Piod0c/OdDbWoR4r48=; b=qsMb5PiTFxXzNpbbBH3PUgwI/OzyfR4NABhf2tMRRIJWj5FInaucFHmHmze2kASWmB TLQraekfJimB7JfnDT1WjY4zX05ub0SSBQ0HGIOb5S4EXphxQh3tI71oPPe6IflK7vLZ PUPSFDBBquF0CrqjxNk3lr/C0ORfgExHYE8zX/agbaT1AdxgmzJOeAJjatojJqV7oBqX i9Q78XUlo+9PFXWiQxbcsDyYtiySjIeI7gVhnj9i8TylWMrlcKlq3u6FyzdlrjYZ4bIH kPyIOtm2ybBmjenitpmiC7CuO1Y6NvXriQxGzNkJNCLu6UjabHtpDFt1f7OoBDhJ9Xem MNpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775089194; x=1775693994; 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=vKJ9BzA17XZF30KI9Dquw4SM4Piod0c/OdDbWoR4r48=; b=lYvV/RTKN42w9/+DUZ9uMOuWEtqZhQoSd7hoYVXamAmJDa5MhGZhiADjy9jB+6P/gx 8cbSIm9szZnHBCSLh4yrxxVe0o3zjNmb6hDSfCz8GWVp5dp6Ow25CY1Sj/79/7K2N5h9 t66U+BEQdMt3l3wi6I7eYDBh2z1vfuJv92B+k3J+BZhBNBLEUoELP8ZjoUCI/6+1H6e9 ze+RmO/PzbiZldA7Q4kojn6LbOgGDpB4/jkvquE3yAMCh2gL1JZwrXzom4VUX08dqXmr SHkIKTS9NxzQjnipcxCAFVZmPHV+zESlbI6CGQtO6P3QNKs4xPOOANZ2HRI1JR0ymNAT GeOw== X-Forwarded-Encrypted: i=1; AJvYcCXWWZCnnE2qT27u1iNgcqsgIhHTQfuXHI7adyM4JCGQhuH50c96mn4S1SZ3i646FZu9UXUUGC/XfCxA9KAz@lists.postgresql.org X-Gm-Message-State: AOJu0YwbekILPK/cuFGkn19F5yIgGK6zbIsJ2hn4z6tZR+A8WVMh1ht0 OFvhrhK5O9DUpFBuIUuPMGSgiqrsRUH9gqz6qgYiNie3Ap4PU1k91GBhjco46zBKzYjea6Lnc6c 3EkANYRuoSNOAjtBB6WLn9FI3uR7vMzI= X-Gm-Gg: ATEYQzwPtc+yJNrWJ2t9ouH1zY1kUow7Vs2LAbhDBObuhjI5VLXDgokxt3Wlk1gH5G3 uCfNmRd7j6K+FIna3zlAIHIRHNBaswWwS/4mzu6ELVuXIs7khMfQ0rsDCDj2qord6es1QclmHXD XIK2wLTRQu+g0qZtHChki/YX0LPz6osOP1Pi0j1Vz97m/d5+5DTCBeugOx8d8R2u85HsIl6Uc/y 8HM4nO2G6492OSmk5zDiR0oZHNnj/E+tva1szLggF9hgfireVPy5mr4tb2nkW9i4Mf+PICxSUwV 8InCbsNe6U0Yw1NkAUm44FtRw9r0qInPcE9eaJWSZ3Z4pxCxVVNRwALvkIVEQptOvjxTxozOD6Y oZpqTqC0fDYV/N8euA6cm2ngyBg== X-Received: by 2002:a05:6122:a21:b0:56a:e1f3:7956 with SMTP id 71dfb90a1353d-56d8a8f1e97mr2558489e0c.11.1775089193858; Wed, 01 Apr 2026 17:19:53 -0700 (PDT) MIME-Version: 1.0 References: <202603311523.iqhng5ljkzpq@alvherre.pgsql> <202603311934.ftqj7ytm362y@alvherre.pgsql> <224730.1775063213@localhost> In-Reply-To: <224730.1775063213@localhost> From: Srinath Reddy Sadipiralla Date: Thu, 2 Apr 2026 05:49:42 +0530 X-Gm-Features: AQROBzDqZTeeXiTZiEsaCBAIaJAaIAyYgWToInEWbN7DD-qZrhYECQ3HX9cxbxU Message-ID: Subject: Re: Adding REPACK [concurrently] To: Antonin Houska Cc: Alvaro Herrera , Amit Kapila , Mihail Nikalayeu , Matthias van de Meent , Pg Hackers , Robert Treat Content-Type: multipart/alternative; boundary="000000000000d8397c064e6f289c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d8397c064e6f289c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antonin, On Wed, Apr 1, 2026 at 10:36=E2=80=AFPM Antonin Houska wro= te: > Srinath Reddy Sadipiralla wrote: > > > i was fuzz testing v48 , and found a crash when REPACK (concurrently) > itself errors out, > > 1) while running > > > > create table test(id int); > > REPACK (concurrently) test; > > > > TBH i didn't knew this, sometimes it's better to not know "rules" ;) > > [NOTE: maybe we should add that we can't run > > REPACK (concurrently) on table without identity index or primary key > into repack.sgml] > > > > ERROR: cannot process relation "test" > > 2026-04-01 19:06:31.211 IST [2495575] HINT: Relation "test" has no > identity index. > > 2026-04-01 19:06:31.211 IST [2495575] STATEMENT: repack (concurrently) > test; > > TRAP: failed Assert("proc->statusFlags =3D=3D > ProcGlobal->statusFlags[proc->pgxactoff]"), File: "procarray.c", Line: 71= 9, > PID: 2495575 > > Here's the diff to solve this crash. > > Thanks. Attached here is v48-0006 fixed. > On Wed, Apr 1, 2026 at 8:25=E2=80=AFPM Srinath Reddy Sadipiralla < srinath2133@gmail.com> wrote: > Here's the diff to solve this crash. diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c > index 29ba49744eb..d44092a407a 100644 > --- a/src/backend/commands/repack.c > +++ b/src/backend/commands/repack.c > @@ -284,7 +284,23 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, boo= l > isTopLevel) > * that others can conflict with. > */ > if ((params.options & CLUOPT_CONCURRENT) !=3D 0) > + { > + /* > + * Do not let other backends wait for our completion during their > + * setup of logical replication. Unlike logical replication publisher, > + * we will have XID assigned, so the other backends - whether > + * walsenders involved in logical replication or regular backends > + * executing also REPACK (CONCURRENTLY) - would have to wait for our > + * completion before they can build their initial snapshot. It is o.k. + * for any decoding backend to ignore us because we do not change > + * tuple descriptor of any table, and the data changes we write should > + * not be decoded by other backends. > + */ > + LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); > MyProc->statusFlags |=3D PROC_IN_CONCURRENT_REPACK; > + ProcGlobal->statusFlags[MyProc->pgxactoff] =3D MyProc->statusFlags; > + LWLockRelease(ProcArrayLock); > + } > > /* > * If a single relation is specified, process it and we're done ... unle= ss > @@ -988,22 +1004,6 @@ rebuild_relation(Relation OldHeap, Relation index, > bool verbose, > > if (concurrent) > { > - /* > - * Do not let other backends wait for our completion during their > - * setup of logical replication. Unlike logical replication publisher, > - * we will have XID assigned, so the other backends - whether > - * walsenders involved in logical replication or regular backends > - * executing also REPACK (CONCURRENTLY) - would have to wait for our > - * completion before they can build their initial snapshot. It is o.k. > - * for any decoding backend to ignore us because we do not change > - * tuple descriptor of any table, and the data changes we write should > - * not be decoded by other backends. > - */ > - LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); > - MyProc->statusFlags |=3D PROC_IN_CONCURRENT_REPACK; > - ProcGlobal->statusFlags[MyProc->pgxactoff] =3D MyProc->statusFlags; > - LWLockRelease(ProcArrayLock); > - > /* > * The worker needs to be member of the locking group we're the leader > * of. We ought to become the leader before the worker starts. The i think as i did earlier in the diff, shouldn't we remove the duplicate cod= e from rebuild_relation, am i missing something? --=20 Thanks, Srinath Reddy Sadipiralla EDB: https://www.enterprisedb.com/ --000000000000d8397c064e6f289c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antonin,

On Wed, Apr 1= , 2026 at 10:36=E2=80=AFPM Antonin Houska <ah@cybertec.at> wrote:
Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:

> i was fuzz testing v48 , and found a crash when REPACK (concurrently) = itself errors out,
> 1) while running
>
> create table test(id int);
> REPACK (concurrently) test;
>
> TBH i didn't knew this, sometimes it's better to not know &quo= t;rules" ;)
> [NOTE: maybe we should add that we can't run
> REPACK (concurrently) on table without identity index or primary key i= nto repack.sgml]
>
> ERROR:=C2=A0 cannot process relation "test"
> 2026-04-01 19:06:31.211 IST [2495575] HINT:=C2=A0 Relation "test&= quot; has no identity index.
> 2026-04-01 19:06:31.211 IST [2495575] STATEMENT:=C2=A0 repack (concurr= ently) test;
> TRAP: failed Assert("proc->statusFlags =3D=3D ProcGlobal->s= tatusFlags[proc->pgxactoff]"), File: "procarray.c", Line:= 719, PID: 2495575
> Here's the diff to solve this crash.

Thanks. Attached here is v48-0006 fixed.

On Wed, Apr 1, 2026 at 8:25=E2=80=AFPM Srinat= h Reddy Sadipiralla <srinath213= 3@gmail.com> wrote:
Here's the diff to solve this crash.
=C2=A0=C2=A0
diff --git a/src/backend/commands/repack= .c b/src/backend/commands/repack.c
index 29ba49744eb..d44092a407a 100644=
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repac= k.c
@@ -284,7 +284,23 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt= , bool isTopLevel)
=C2=A0 * that others can conflict with.
=C2=A0 */<= br>=C2=A0 if ((params.options & CLUOPT_CONCURRENT) !=3D 0)
+ {
+ = /*
+ * Do not let other backends wait for our completion during their+ * setup of logical replication. Unlike logical replication publisher,+ * we will have XID assigned, so the other backends - whether
+ * wals= enders involved in logical replication or regular backends
+ * executing= also REPACK (CONCURRENTLY) - would have to wait for our
+ * completion = before they can build their initial snapshot. It is o.k.
+ * for any decoding backend to= ignore us because we do not change
+ * tuple descriptor of any table, a= nd the data changes we write should
+ * not be decoded by other backends= .
+ */
+ LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
=C2=A0 MyProc= ->statusFlags |=3D PROC_IN_CONCURRENT_REPACK;
+ ProcGlobal->status= Flags[MyProc->pgxactoff] =3D MyProc->statusFlags;
+ LWLockRelease(= ProcArrayLock);
+ }
=C2=A0
=C2=A0 /*
=C2=A0 * If a single relat= ion is specified, process it and we're done ... unless
@@ -988,22 +1= 004,6 @@ rebuild_relation(Relation OldHeap, Relation index, bool verbose,=C2=A0
=C2=A0 if (concurrent)
=C2=A0 {
- /*
- * Do not let ot= her backends wait for our completion during their
- * setup of logical r= eplication. Unlike logical replication publisher,
- * we will have XID a= ssigned, so the other backends - whether
- * walsenders involved in logi= cal replication or regular backends
- * executing also REPACK (CONCURREN= TLY) - would have to wait for our
- * completion before they can build t= heir initial snapshot. It is o.k.
- * for any decoding backend to ignore= us because we do not change
- * tuple descriptor of any table, and the = data changes we write should
- * not be decoded by other backends.
- = */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyProc->statusF= lags |=3D PROC_IN_CONCURRENT_REPACK;
- ProcGlobal->statusFlags[MyProc= ->pgxactoff] =3D MyProc->statusFlags;
- LWLockRelease(ProcArrayLoc= k);
-
=C2=A0 /*
=C2=A0 * The worker needs to be member of the lock= ing group we're the leader
=C2=A0 * of. We ought to become the leade= r before the worker starts. The=C2=A0
i think as i d= id earlier in the diff, shouldn't we remove the duplicate code
from = rebuild_relation, am i missing something?


--
=
Thanks,
Srinath Reddy Sadipiralla
EDB:=C2=A0<= a href=3D"https://www.enterprisedb.com/" style=3D"color:rgb(17,85,204)" tar= get=3D"_blank">https://www.enterprisedb.com/
--000000000000d8397c064e6f289c--