Re: Adding REPACK [concurrently]

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

In response to

Browse pgsql-hackers by date

  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