Re: Adding REPACK [concurrently]

Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> wrote:

> Hello!
>
> On Sat, Dec 13, 2025 at 7:45 PM Mihail Nikalayeu
> <mihailnikalayeu(at)gmail(dot)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