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 1w7wzM-00045j-03 for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 14:56:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7wzK-000k8d-2H for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 14:56:11 +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 1w7wzK-000k8U-0W for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 14:56:10 +0000 Received: from mail-vs1-xe34.google.com ([2607:f8b0:4864:20::e34]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w7wzI-000000001hS-1EcW for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 14:56:09 +0000 Received: by mail-vs1-xe34.google.com with SMTP id ada2fe7eead31-604fc147b7cso1908182137.2 for ; Wed, 01 Apr 2026 07:56:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775055367; cv=none; d=google.com; s=arc-20240605; b=dvyzRlfd6pr2/+Bz5GYnL3JDjH2OTb36R/co77+pSPuQuD2IYx6RjrOz4m+3utgy5n zWG1UrE9rH92QydeXEzHX3uNTDUztiatJT9nJixCZ9SrBCqq5prgLKv0mo3FQpvet9t9 G7c2Rp/PwRT5lrxNhJ5LCAA4aNbGXt4mtl5KLG6cjyMhclZFw22PD4i9acEXYsKXvEfF F1U2LGVFVz8ZuYgkjDAQh1CTk0Ax4l+RnEr6VhNezG+RS298T/LqpirrR9BVeQc1n/+h fxQs2fqujWKAosg5rWo6+bkeOIJs7Nx/WDfRxa2ZYv9jaS3QiNgp6W96dF8xaW506oYr /JQw== 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=vkzAl2AO1NJdzWU+W+SKU7674zO+Bp+ZBHAQoGwftoc=; fh=t4FrRnW9cLAZ1QM54/CxFSNV8JlGAjMqCl2TXbi+sRQ=; b=k47tJMgprsm+R4rKlK3/NzIBSbcZUBTB2qcU6rmSiqUx26NqI73JOeSCdXCPzRO2JG 0glivR8RR/cZCFqLvwVWWVDQtY3elVoiP8cAtPwSsZVW1hYTLDK0erzZboVdEnhtqp1g ORrCTanNXLfsADqvMHaYhHywqj56BzrFqY9yRzKIUGllWEcXXVqwyMJgCr36Zu58dZdF nAD9AyFJojzrsKck448pt75fJ5fFyJkPl24QzK+00mnGF/ZcKeKoBdUm7AXtjSdzuNRs 71jG9d5x3E59quNvIlnGWS8ghhIrcPeA44Rv0QHLBpbWY+Gm270m01DQT+OWVFcRlneG Dkjg==; 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=1775055367; x=1775660167; 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=vkzAl2AO1NJdzWU+W+SKU7674zO+Bp+ZBHAQoGwftoc=; b=nzOg5SKKcvOGRJiSEMaAKWuO8FFGTPOecb2UqTfUJmeXn7uCD3Nav7VLDeeKbbrfhS T05KU5iMs6OhLd5O2N/QPeuF9Ce02K1svwY4MxjqU1YGwZCRvuUx+qAtaBn+bwV8dmPN c2vXXPlMu09s4bSF7NyRzKYLn4O/Llli9b2T3QxXCdxZn8vkdHIenwTQUNxZ24aFkgP/ oc5ET/z4Z6tYRHrNnizHIddGuKpGD0QByhfGYdiATEWQyG6QXvTjNrKZAmkfMlEFRf/t woVB7Ka66H0H3+2ucF9oHTIsYShErROtp26angDKRQYb6ADDqp60IjufMIQDe2mRFg50 YAFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775055367; x=1775660167; 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=vkzAl2AO1NJdzWU+W+SKU7674zO+Bp+ZBHAQoGwftoc=; b=BZLk5MfpKY+aXG4MzEm6sTw/+jho607aogmPAoXzkC3+vVGelUzbkyg89ePSdkZAim F7987s7TWLhn/lwWgI9qe3B1qNj7DbWGplDj9aD4uH5pW+DeY6J0YcdbBmzdMuJqJpej eKTpbO+wG/MVaeXcZhWovifxnLrNFDCT4HNkw9G01vynhx39w+g9vPt5Vu3uKFzdetAT 0SEVoKlcSR/XtfR+cZZMSsLTyZ59UiL1HaZ0l8jb+F5zUA1em7o9qPjlmSctkCGQIMN9 2H6RnmSTqlMojGu4GsWWasVAxxZtIgjKrUA1RfE5HyumxYO5DR9hQng1i46IO6zNM/4S XTNg== X-Forwarded-Encrypted: i=1; AJvYcCVYHDSZGQFW4PDMezKVkUSWEf9J/Bybm31oBkd3IQ2ZG/G6e3/I0wzATLmuMMtpB5RSWVOabn10tbbpCqD/@lists.postgresql.org X-Gm-Message-State: AOJu0YzjhTkeathJC7mubPARodDPn6RSVl16IyvPlfpPg7kOu6eipvaQ A9kmvBBCFpWMrGGkYwD40iCkPPmIhTsCS4WR3mubesMSPGoOVZlw9/2zLA2BW39j8XwAjCNcNOL qjAj9vnlcjY9e6Hdnv906mWewdNpfzL4= X-Gm-Gg: ATEYQzw5iy4ly5aKEJ/DJ4SSeB6gATw/vj5SEdv2CQZlR/rS2GafFtwLQAmZo7/1GjT 2d1cwkboaR6G6+RmNbKtLDAZrAzHTqf00Mo+g3Ltm7k905dyN+IHaKoJx8lrsC72xO7Ox2pqJdi X3KUku4Z5QkQ9S5rK29dOGEgf4AjMtaaibef2HX8J3T8DMWYOWN5ahBGwpbvRYk8uMcWDk40K4w 8aT0E2NbGFW8c+yjjo8Qx4Da4fx6epykgLF2ta9qbgjVL4Brno5kGPnkKhAl5TciJ6uyYjjMyb/ MF4lOa3hvIKVayNkJ3ZUbO/Rv/R8oOzo9Iyeo7+GkcrZeIq0q/VvxdbKj3SMzEFjkwF6oJqKqne YVbnLZDtYrVOOll1gaK9VBrSMmQ== X-Received: by 2002:a05:6102:2b95:b0:605:4cbd:91ad with SMTP id ada2fe7eead31-60567d7e88cmr1180234137.6.1775055366893; Wed, 01 Apr 2026 07:56:06 -0700 (PDT) MIME-Version: 1.0 References: <202603311523.iqhng5ljkzpq@alvherre.pgsql> <202603311934.ftqj7ytm362y@alvherre.pgsql> In-Reply-To: <202603311934.ftqj7ytm362y@alvherre.pgsql> From: Srinath Reddy Sadipiralla Date: Wed, 1 Apr 2026 20:25:54 +0530 X-Gm-Features: AQROBzAZ284qdoygQwG85Wrz3ItLU15-lfevR5Npl0Uz6GPrppVCNKv8eHiiH88 Message-ID: Subject: Re: Adding REPACK [concurrently] To: Alvaro Herrera Cc: Antonin Houska , Amit Kapila , Mihail Nikalayeu , Matthias van de Meent , Pg Hackers , Robert Treat Content-Type: multipart/alternative; boundary="00000000000099b8bf064e67488d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000099b8bf064e67488d Content-Type: text/plain; charset="UTF-8" Hello, 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 == ProcGlobal->statusFlags[proc->pgxactoff]"), File: "procarray.c", Line: 719, PID: 2495575 postgres: srinath postgres [local] REPACK(ExceptionalCondition+0x98)[0xaaaaad938d84] postgres: srinath postgres [local] REPACK(ProcArrayEndTransaction+0x1f0)[0xaaaaad6c15fc] postgres: srinath postgres [local] REPACK(+0x210cf0)[0xaaaaad190cf0] postgres: srinath postgres [local] REPACK(+0x2117e4)[0xaaaaad1917e4] postgres: srinath postgres [local] REPACK(AbortCurrentTransaction+0x10)[0xaaaaad191740] postgres: srinath postgres [local] REPACK(PostgresMain+0x568)[0xaaaaad7116e4] postgres: srinath postgres [local] REPACK(+0x786ae0)[0xaaaaad706ae0] postgres: srinath postgres [local] REPACK(postmaster_child_launch+0x1f0)[0xaaaaad5d719c] postgres: srinath postgres [local] REPACK(+0x65ea98)[0xaaaaad5dea98] postgres: srinath postgres [local] REPACK(+0x65b650)[0xaaaaad5db650] postgres: srinath postgres [local] REPACK(PostmasterMain+0x1564)[0xaaaaad5dae1c] postgres: srinath postgres [local] REPACK(main+0x3dc)[0xaaaaad466348] /lib/aarch64-linux-gnu/libc.so.6(+0x284c4)[0xffffb40d84c4] /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0xffffb40d8598] postgres: srinath postgres [local] REPACK(_start+0x30)[0xaaaaad06ddf0] 2026-04-01 19:06:31.800 IST [2494560] LOG: client backend (PID 2495575) was terminated by signal 6: Aborted 2) And when running REPACK (concurrently) on the same table while already a repack was running on the same table ,just to verify the deadlock occurs and gets errored out that "could not wait for concurrent REPACK" but instead got the same crash. ERROR: could not wait for concurrent REPACK 2026-04-01 12:55:39.481 IST [2397660] DETAIL: Process 2397660 waits for REPACK running on process 2397307 2026-04-01 12:55:39.481 IST [2397660] CONTEXT: waiting for ShareUpdateExclusiveLock on relation 16385 of database 5 2026-04-01 12:55:39.481 IST [2397660] STATEMENT: repack (concurrently) stress_victim ; 2026-04-01 12:55:39.497 IST [2397151] LOG: checkpoint complete: time: wrote 2056 buffers (12.5%), wrote 0 SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=206.804 s, sync=0.003 s, total=861.616 s; sync files=17, longest=0.002 s, average=0.001 s; distance=318978 kB, estimate=515341 kB; lsn=2/02810A60, redo lsn=2/02810910 TRAP: failed Assert("proc->statusFlags == ProcGlobal->statusFlags[proc->pgxactoff]"), File: "procarray.c", Line: 719, PID: 2397660 postgres: srinath postgres [local] REPACK(ExceptionalCondition+0x98)[0xaaaae7d58d84] postgres: srinath postgres [local] REPACK(ProcArrayEndTransaction+0x1f0)[0xaaaae7ae15fc] postgres: srinath postgres [local] REPACK(+0x210cf0)[0xaaaae75b0cf0] postgres: srinath postgres [local] REPACK(+0x2117e4)[0xaaaae75b17e4] postgres: srinath postgres [local] REPACK(AbortCurrentTransaction+0x10)[0xaaaae75b1740] postgres: srinath postgres [local] REPACK(PostgresMain+0x568)[0xaaaae7b316e4] postgres: srinath postgres [local] REPACK(+0x786ae0)[0xaaaae7b26ae0] postgres: srinath postgres [local] REPACK(postmaster_child_launch+0x1f0)[0xaaaae79f719c] postgres: srinath postgres [local] REPACK(+0x65ea98)[0xaaaae79fea98] postgres: srinath postgres [local] REPACK(+0x65b650)[0xaaaae79fb650] postgres: srinath postgres [local] REPACK(PostmasterMain+0x1564)[0xaaaae79fae1c] postgres: srinath postgres [local] REPACK(main+0x3dc)[0xaaaae7886348] /lib/aarch64-linux-gnu/libc.so.6(+0x284c4)[0xffff9ec984c4] /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0xffff9ec98598] postgres: srinath postgres [local] REPACK(_start+0x30)[0xaaaae748ddf0] 2026-04-01 12:58:18.198 IST [2397147] LOG: client backend (PID 2397660) was terminated by signal 6: Aborted the reason for this crash was ProcGlobal->statusFlags was not initialized during the start of ExecRepack , earlier Abort before reaching the proper initialization of ProcGlobal->statusFlags which was done in rebuild_relation caused this assert failure in ProcArrayEndTransaction. 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, bool isTopLevel) * that others can conflict with. */ if ((params.options & CLUOPT_CONCURRENT) != 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 |= PROC_IN_CONCURRENT_REPACK; + ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; + LWLockRelease(ProcArrayLock); + } /* * If a single relation is specified, process it and we're done ... unless @@ -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 |= PROC_IN_CONCURRENT_REPACK; - ProcGlobal->statusFlags[MyProc->pgxactoff] = 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 Thoughts? -- Thanks, Srinath Reddy Sadipiralla EDB: https://www.enterprisedb.com/ --00000000000099b8bf064e67488d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

i was fuzz testing v4= 8 , and found a crash when REPACK (concurrently) itself errors out,
1) w= hile running

create table test(id int);
REPACK (concurrently) tes= t;

TBH i didn't knew this, sometimes it's better to not know= "rules" ;)
[NOTE: maybe we should add that we can't runREPACK (concurrently) on table without identity=C2=A0index or primary key= into repack.sgml]

ERROR: =C2=A0cannot process relation "test&q= uot;
2026-04-01 19:06:31.211 IST [2495575] HINT: =C2=A0Relation "te= st" has no identity index.
2026-04-01 19:06:31.211 IST [2495575] ST= ATEMENT: =C2=A0repack (concurrently) test;
TRAP: failed Assert("pro= c->statusFlags =3D=3D ProcGlobal->statusFlags[proc->pgxactoff]&quo= t;), File: "procarray.c", Line: 719, PID: 2495575
postgres: sr= inath postgres [local] REPACK(ExceptionalCondition+0x98)[0xaaaaad938d84]postgres: srinath postgres [local] REPACK(ProcArrayEndTransaction+0x1f0)[0= xaaaaad6c15fc]
postgres: srinath postgres [local] REPACK(+0x210cf0)[0xaa= aaad190cf0]
postgres: srinath postgres [local] REPACK(+0x2117e4)[0xaaaaa= d1917e4]
postgres: srinath postgres [local] REPACK(AbortCurrentTransacti= on+0x10)[0xaaaaad191740]
postgres: srinath postgres [local] REPACK(Postg= resMain+0x568)[0xaaaaad7116e4]
postgres: srinath postgres [local] REPACK= (+0x786ae0)[0xaaaaad706ae0]
postgres: srinath postgres [local] REPACK(po= stmaster_child_launch+0x1f0)[0xaaaaad5d719c]
postgres: srinath postgres = [local] REPACK(+0x65ea98)[0xaaaaad5dea98]
postgres: srinath postgres [lo= cal] REPACK(+0x65b650)[0xaaaaad5db650]
postgres: srinath postgres [local= ] REPACK(PostmasterMain+0x1564)[0xaaaaad5dae1c]
postgres: srinath postgr= es [local] REPACK(main+0x3dc)[0xaaaaad466348]
/lib/aarch64-linux-gnu/lib= c.so.6(+0x284c4)[0xffffb40d84c4]
/lib/aarch64-linux-gnu/libc.so.6(__libc= _start_main+0x98)[0xffffb40d8598]
postgres: srinath postgres [local] REP= ACK(_start+0x30)[0xaaaaad06ddf0]
2026-04-01 19:06:31.800 IST [2494560] L= OG: =C2=A0client backend (PID 2495575) was terminated by signal 6: Aborted<= br>

2) And when running REPACK (concurrently) on the same table whil= e already a repack was running
on the same table ,just to verify the dea= dlock occurs and gets errored out that
"could not wait for concurre= nt REPACK" but instead got the same crash.

ERROR: =C2=A0could n= ot wait for concurrent REPACK
2026-04-01 12:55:39.481 IST [2397660] DETA= IL: =C2=A0Process 2397660 waits for REPACK running on process 2397307
20= 26-04-01 12:55:39.481 IST [2397660] CONTEXT: =C2=A0waiting for ShareUpdateE= xclusiveLock on relation 16385 of database 5
2026-04-01 12:55:39.481 IST= [2397660] STATEMENT: =C2=A0repack (concurrently) stress_victim ;
2026-0= 4-01 12:55:39.497 IST [2397151] LOG: =C2=A0checkpoint complete: time: wrote= 2056 buffers (12.5%), wrote 0 SLRU buffers; 0 WAL file(s) added, 0 removed= , 0 recycled; write=3D206.804 s, sync=3D0.003 s, total=3D861.616 s; sync fi= les=3D17, longest=3D0.002 s, average=3D0.001 s; distance=3D318978 kB, estim= ate=3D515341 kB; lsn=3D2/02810A60, redo lsn=3D2/02810910
TRAP: failed As= sert("proc->statusFlags =3D=3D ProcGlobal->statusFlags[proc->= pgxactoff]"), File: "procarray.c", Line: 719, PID: 2397660postgres: srinath postgres [local] REPACK(ExceptionalCondition+0x98)[0xaa= aae7d58d84]
postgres: srinath postgres [local] REPACK(ProcArrayEndTransa= ction+0x1f0)[0xaaaae7ae15fc]
postgres: srinath postgres [local] REPACK(+= 0x210cf0)[0xaaaae75b0cf0]
postgres: srinath postgres [local] REPACK(+0x2= 117e4)[0xaaaae75b17e4]
postgres: srinath postgres [local] REPACK(AbortCu= rrentTransaction+0x10)[0xaaaae75b1740]
postgres: srinath postgres [local= ] REPACK(PostgresMain+0x568)[0xaaaae7b316e4]
postgres: srinath postgres = [local] REPACK(+0x786ae0)[0xaaaae7b26ae0]
postgres: srinath postgres [lo= cal] REPACK(postmaster_child_launch+0x1f0)[0xaaaae79f719c]
postgres: sri= nath postgres [local] REPACK(+0x65ea98)[0xaaaae79fea98]
postgres: srinat= h postgres [local] REPACK(+0x65b650)[0xaaaae79fb650]
postgres: srinath p= ostgres [local] REPACK(PostmasterMain+0x1564)[0xaaaae79fae1c]
postgres: = srinath postgres [local] REPACK(main+0x3dc)[0xaaaae7886348]
/lib/aarch64= -linux-gnu/libc.so.6(+0x284c4)[0xffff9ec984c4]
/lib/aarch64-linux-gnu/li= bc.so.6(__libc_start_main+0x98)[0xffff9ec98598]
postgres: srinath postgr= es [local] REPACK(_start+0x30)[0xaaaae748ddf0]
2026-04-01 12:58:18.198 I= ST [2397147] LOG: =C2=A0client backend (PID 2397660) was terminated by sign= al 6: Aborted

the reason for this crash was=C2=A0ProcGlobal->stat= usFlags was not initialized
during the start of=C2=A0ExecRepack , earlie= r Abort before reaching the proper
initialization of ProcGlobal->stat= usFlags which was done in=C2=A0rebuild_relation
caused this assert failu= re in=C2=A0ProcArrayEndTransaction.

Here's the diff to solve thi= s crash.

diff --git a/src/backend/commands/repack.c b/src/backend/co= mmands/repack.c
index 29ba49744eb..d44092a407a 100644
--- a/src/backe= nd/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -284,7 +2= 84,23 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel)<= br>=C2=A0 * that others can conflict with.
=C2=A0 */
=C2=A0 if ((pa= rams.options & CLUOPT_CONCURRENT) !=3D 0)
+ {
+ /*
+ * Do n= ot let other backends wait for our completion during their
+ * setup o= f logical replication. Unlike logical replication publisher,
+ * we wi= ll have XID assigned, so the other backends - whether
+ * walsenders i= nvolved in logical replication or regular backends
+ * executing also = REPACK (CONCURRENTLY) - would have to wait for our
+ * completion befo= re they can build their initial snapshot. It is o.k.
+ * for any decod= ing 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_EXCLUSI= VE);
=C2=A0 MyProc->statusFlags |=3D PROC_IN_CONCURRENT_REPACK;
+= ProcGlobal->statusFlags[MyProc->pgxactoff] =3D MyProc->statusFla= gs;
+ LWLockRelease(ProcArrayLock);
+ }
=C2=A0
=C2=A0 /*
= =C2=A0 * If a single relation is specified, process it and we're done = ... unless
@@ -988,22 +1004,6 @@ rebuild_relation(Relation OldHeap, Rela= tion index, bool verbose,
=C2=A0
=C2=A0 if (concurrent)
=C2=A0 {- /*
- * Do not let other backends wait for our completion during t= heir
- * setup of logical replication. Unlike logical replication publ= isher,
- * we will have XID assigned, so the other backends - whether<= br>- * 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(Proc= ArrayLock, LW_EXCLUSIVE);
- MyProc->statusFlags |=3D PROC_IN_CONCURR= ENT_REPACK;
- ProcGlobal->statusFlags[MyProc->pgxactoff] =3D MyPr= oc->statusFlags;
- LWLockRelease(ProcArrayLock);
-
=C2=A0 /*<= br>=C2=A0 * The worker needs to be member of the locking group we're = the leader
=C2=A0 * of. We ought to become the leader before the worke= r starts. The


Thoughts?

--
Thank= s,
Srinath Reddy Sadipiralla
EDB:=C2=A0https://www= .enterprisedb.com/
--00000000000099b8bf064e67488d--