From: Antonin Houska <ah@cybertec.at>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <CADzfLwWNz_jwi7KVOmJ9D97+zwxsiwDSqSUUJ9oqUCOqkbGnRA@mail.gmail.com>
References: <202510301734.pj4uds3mqxx4@alvherre.pgsql> <116433.1764870207@localhost> <CADzfLwWFbXVN-QrKaVXvW96eYQD1AiRVCYd99nX7EQFG3q_yfg@mail.gmail.com> <CADzfLwWS6Ukme5uhv9=1ZyyG=D5Bp0dE+zGn=qcfGV=jSY6mpw@mail.gmail.com> <CADzfLwXudUtPi1xFC_CBpGP=vSmDY4pAvBbS4_BCwOUyNTT5WA@mail.gmail.com> <171530.1765306357@localhost> <CADzfLwXp4c-MJx7yVDxAGNNxPbX4o9dqyivxavtHvmUsdXYqBQ@mail.gmail.com> <CADzfLwUitd5J17O9FUxNGrZBurOpL6n+tnS6dgArXi-i9DNxhg@mail.gmail.com> <CADzfLwWNz_jwi7KVOmJ9D97+zwxsiwDSqSUUJ9oqUCOqkbGnRA@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Thu, 18 Dec 2025 02:47:00 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Mon, 05 Jan 2026 11:54:07 +0100
Message-ID: <12236.1767610447@localhost>
Archived-At: <https://www.postgresql.org/message-id/12236.1767610447%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> Hello!
>=20
> On Sat, Dec 13, 2025 at 7:45=E2=80=AFPM Mihail Nikalayeu
> <mihailnikalayeu@gmail.com> wrote:
> > Stress tests for REPACK concurrently in attachment.
>=20
> To run:
> ninja && meson test --suite setup && meson test --print-errorlogs
> --suite amcheck *007*
> ninja && meson test --suite setup && meson test --print-errorlogs
> --suite amcheck *008*

Thanks for running the tests!

> Results for v28:
>=20
> Up to " v28-0005-Use-background-worker-to-do-logical-decoding.patch":
>=20
> Technically it passes, but sometimes I saw 0% CPU usage for long
> periods with such stacks (looks like it happens for 0008 more often):

...

> Probably it is because
> > 100000L,    /* XXX Tune the delay. */
>=20
> 100 seconds is clearly too much.

I confused milliseconds with microseconds. Since I was only running the code
with debugger, the long delays didn't appear to be a problem.

Instead of tuning the timeout, I'm thinking of introducing a condition
variable that signals WAL flushing.

> For "v28-0006-Use-multiple-snapshots-to-copy-the-data.patch":
>=20
> 0007: crash with
>=20
> TRAP: failed Assert("portal->portalSnapshot =3D=3D GetActiveSnapshot()"),
> File: "../src/backend/tcop/pquery.c", Line: 1169, PID: 178414

Thanks. I'll check when I have time for this part.

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