From: Antonin Houska <ah@cybertec.at>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Cc: alvherre@alvh.no-ip.org,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <4200.1772781295@localhost>
References: <202602241757.6ac3iss2u4vo@alvherre.pgsql>
 <9116.1772009759@localhost>
 <CAFC+b6o2yzA80YmfEhmMO9puN8qvGRvr-15BBLn3UmJxPfpr2w@mail.gmail.com>
 <100248.1772048475@localhost> <4200.1772781295@localhost>
Comments: In-reply-to Antonin Houska <ah@cybertec.at>
   message dated "Fri, 06 Mar 2026 08:14:55 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29156.1774029970.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Mar 2026 19:06:10 +0100
Message-ID: <29157.1774029970@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/29157.1774029970%40localhost>
Precedence: bulk

Antonin Houska <ah@cybertec.at> wrote:

> Antonin Houska <ah@cybertec.at> wrote:
> =

> > Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:
> > =

> > > The concurrency test failed once. I tried to reproduce the below sce=
nario
> > > but no luck,i think the reason the assert failure happened because
> > > after speculative insert there might be no spec CONFIRM or ABORT, th=
oughts?
> > =

> > Perhaps, I'll try. I'm not sure the REPACK decoding worker does anthin=
g
> > special regarding decoding. If you happen to see the problem again, pl=
ease try
> > to preserve the related WAL segments - if this is a bug in PG executor=
,
> > pg_waldump might reveal that.
> =

> I could not reproduce the failure, and have no idea how speculative inse=
rt can
> stay w/o CONFIRM / ABORT record. The only problem I could imagine is tha=
t
> change_useless_for_repack() filters out the CONFIRM / ABORT record
> accidentally, but neither code review nor debugger proves that
> theory. (Actually if this was the problem, the test failure probably wou=
ldn't
> be that rare.)

I confirm that I was able to reproduce the crash using debugger and your m=
ore
recent diagnosis [1]. Indeed, filtering was the problem.

Unfortunately, I wasn't able to make the crash easily reproducible using
isolation tester. The problem is that the logical decoding is performed by=
 a
background worker, and when the backend executing REPACK waits for the
background worker, which in turn waits on an injection point, the isolatio=
n
tester does not recognize that it's effectively the backend who is waiting=
 on
the injection point. Therefore the isolation tester does not proceed to th=
e
next step.

Anyway, thanks again for your testing!

[1] https://www.postgresql.org/message-id/CAFC%2Bb6qk3-DQTi43QMqvVLP%2Bsud=
PV4vsLQm5iHfcCeObrNaVyA%40mail.gmail.com

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com