Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:
> Hello!
>
> On Sat, Dec 13, 2025 at 7:45 PM Mihail Nikalayeu
> <mihailnikalayeu@gmail.com> wrote:
> > Stress tests for REPACK concurrently in attachment.
>
> 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:
>
> Up to " v28-0005-Use-background-worker-to-do-logical-decoding.patch":
>
> 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. */
>
> 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":
>
> 0007: crash with
>
> TRAP: failed Assert("portal->portalSnapshot == GetActiveSnapshot()"),
> File: "../src/backend/tcop/pquery.c", Line: 1169, PID: 178414
Thanks. I'll check when I have time for this part.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
