| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-01-05 14:59:32 |
| Message-ID: | 26358.1767625172@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On 2026-Jan-05, Antonin Houska wrote:
>
> > Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> wrote:
>
> > > 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.
>
> I think there is a patch that adds support for this in the queue already
> -- see this message:
> https://postgr.es/m/CAPpHfds-KiZRuCruc0jHxLSxLqzKcHJGwOFFA0b_RgaJvtUOEQ@mail.gmail.com
Thanks for the hint! It seems that the already committed WaitForLSN() function
does what I need.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-01-05 15:00:15 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Aleksander Alekseev | 2026-01-05 14:51:58 | Re: [PATCH] Precompute string lengths in PerformRadiusTransaction |