From: Antonin Houska <ah@cybertec.at>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Amit Kapila <amit.kapila16@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>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <85813.1777901089@localhost>
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>
Comments: In-reply-to Antonin Houska <ah@cybertec.at>
   message dated "Mon, 04 May 2026 15:24:49 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Tue, 05 May 2026 14:47:46 +0200
Message-ID: <27869.1777985266@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/27869.1777985266%40localhost>
Precedence: bulk

Antonin Houska <ah@cybertec.at> wrote:

> Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:
>=20
> > On Mon, Apr 27, 2026 at 6:25=E2=80=AFAM Amit Kapila <amit.kapila16@gmai=
l.com> wrote:
> > > Alvaro, others, what is your take on this?
> >=20
> > I agree with you here - we should AT LEAST make that an ERROR instead
> > of an assert and also check it during cache access (not only during
> > the scan because of cache misses).
> > But I think it will still be fragile in case of some extensions install=
ed.
> >=20
> > Anyway... We also have an issue with correctness right now.
> >=20
> > I took the old stress test from [0] (the first two) and it fails now,
> > even with the fix from [1] ("Possible premature SNAPBUILD_CONSISTENT
> > with DB-specific running_xacts").
> >=20
> > It looks like [1] fixes 008_repack_concurrently.pl, but
> > 007_repack_concurrently.pl fails anyway, including
> >=20
> >      pgbench: error: client 1 script 0 aborted in command 10 query 0:
> > ERROR:  could not create unique index "tbl_pkey_repacknew"
> >      # DETAIL:  Key (i)=3D(383) is duplicated.
> > and
> >      'pgbench: error: pgbench:client 23 script 0 aborted in command 31
> > query 0: ERROR:  division by zero
> >=20
> > Last one is not MVCC-related; you can see from the logs that it
> > performs something like SELECT (509063) / 0 when the table sum
> > changes.
> >=20
> > Setting need_shared_catalogs =3D true make them pass, so something is
> > wrong with its correctness.
>=20
> Thanks for testing again. Whether we keep the "database specific slots" or
> not, it'd be good to know what exactly the reason of these errors is. I w=
onder
> if the feature just exposes a problem that remains shadowed otherwise, du=
e to
> the contention on replication slot. I'm going to investigate.

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 CONSISTENT state
	 * faster, however the code below makes no use of it. Moreover, such
	 * record might cause problems because the following normal (cluster-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 may
continue to be incorrectly considered running.

I originally thought that this should not happen because such transactions
will be added to the builder's array of committed transactions by
SnapBuildCommitTxn() anyway. However, I failed to notice that COMMIT record=
 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.

I've got no good idea how to fix that. Not sure I'm able to pursue the
"database-specific snapshots" feature now.

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