From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <202601051404.qkpher3pinlm@alvherre.pgsql>
References: <202601051404.qkpher3pinlm@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
   message dated "Mon, 05 Jan 2026 11:07:00 -0300."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26357.1767625172.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 05 Jan 2026 15:59:32 +0100
Message-ID: <26358.1767625172@localhost>
Archived-At: <https://www.postgresql.org/message-id/26358.1767625172%40localhost>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> On 2026-Jan-05, Antonin Houska wrote:
> =

> > Mihail Nikalayeu <mihailnikalayeu@gmail.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 th=
e 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() func=
tion
does what I need.

-- =

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