MIME-Version: 1.0
References: 
 <CAA4eK1Jg21ODQ7fS2fvN5W_S5kDRhAP5inj3XMRQaa=s-GbYhw@mail.gmail.com>
 <202604071230.b5axxf3qna3m@alvherre.pgsql>
 <cdgw4sbbfcgk6du3iv54r2dgiy4tfywoklbotlmj4irxavdcr3@glxfw5jj277q>
 <227677.1775576304@localhost>
 <pveffyxhnuurhb44uzqlwo3rkyzorkfh2rot7uwzlf2axhfvbp@7nrs2omysxkc>
 <CAA4eK1JhuT5fyTosWDZ+Pgs+j7xEjObTyRMn80uNKgi_ivqHbw@mail.gmail.com>
 <CADzfLwWnbKcb3v8sStdgNE=WNc3uUqx5SiS4zftX2UaEfNzG5w@mail.gmail.com>
 <85813.1777901089@localhost> <27869.1777985266@localhost>
In-Reply-To: <27869.1777985266@localhost>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Sun, 10 May 2026 17:01:04 +0530
Message-ID: 
 <CAA4eK1KC6CGN-N2bUffSign8Sw4q6=8d3L-Xh4t+50GCdQb6zw@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Antonin Houska <ah@cybertec.at>
Cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
 Andres Freund <andres@anarazel.de>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>,
 Robert Treat <rob@xzilla.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1KC6CGN-N2bUffSign8Sw4q6%3D8d3L-Xh4t%2B50GCdQb6zw%40mail.gmail.com>
Precedence: bulk

On Tue, May 5, 2026 at 6:17=E2=80=AFPM Antonin Houska <ah@cybertec.at> wrot=
e:
>
> Antonin Houska <ah@cybertec.at> wrote:
>
> I think the problem is that with database-specific snapshot,
> SnapBuildProcessRunningXacts() returns early, w/o adjusting builder->xmin
>
>         /*
>          * Database specific transaction info may exist to reach CONSISTE=
NT state
>          * faster, however the code below makes no use of it. Moreover, s=
uch
>          * record might cause problems because the following normal (clus=
ter-wide)
>          * record can have lower value of oldestRunningXid. In that case,=
 let's
>          * wait with the cleanup for the next regular cluster-wide record=
.
>          */
>         if (OidIsValid(running->dbid))
>                 return;
>
> and thus some transactions whose XID is below running->oldestRunningXid m=
ay
> continue to be incorrectly considered running.
>
> I originally thought that this should not happen because such transaction=
s
> will be added to the builder's array of committed transactions by
> SnapBuildCommitTxn() anyway. However, I failed to notice that COMMIT reco=
rd of
> a transaction listed in the xl_running_xacts WAL record is not guaranteed=
 to
> follow the xl_running_xacts record in WAL. In other words, even if
> xl_running_xacts is created before a COMMIT record of the contained
> transaction, it may end up at higher LSN in WAL. So the cleanup I relied =
on
> might not take place.
>

BTW, is it possible to write a test by using injection_points or via
manual steps (by using debugger, etc) so that we can more clearly
understand this problem and proposed fix?

--=20
With Regards,
Amit Kapila.