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: <100248.1772048475@localhost>
References: <202602241757.6ac3iss2u4vo@alvherre.pgsql>
 <9116.1772009759@localhost>
 <CAFC+b6o2yzA80YmfEhmMO9puN8qvGRvr-15BBLn3UmJxPfpr2w@mail.gmail.com>
 <100248.1772048475@localhost>
Comments: In-reply-to Antonin Houska <ah@cybertec.at>
   message dated "Wed, 25 Feb 2026 20:41:15 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4199.1772781295.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 06 Mar 2026 08:14:55 +0100
Message-ID: <4200.1772781295@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/4200.1772781295%40localhost>
Precedence: bulk

Antonin Houska <ah@cybertec.at> wrote:

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

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

> Perhaps, I'll try. I'm not sure the REPACK decoding worker does anthing
> special regarding decoding. If you happen to see the problem again, plea=
se 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 insert=
 can
stay w/o CONFIRM / ABORT record. The only problem I could imagine is that
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 would=
n't
be that rare.)

-- =

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