MIME-Version: 1.0
References: <202510301734.pj4uds3mqxx4@alvherre.pgsql>
 <116433.1764870207@localhost>
 <CADzfLwWFbXVN-QrKaVXvW96eYQD1AiRVCYd99nX7EQFG3q_yfg@mail.gmail.com>
 <CADzfLwWS6Ukme5uhv9=1ZyyG=D5Bp0dE+zGn=qcfGV=jSY6mpw@mail.gmail.com>
 <CADzfLwXudUtPi1xFC_CBpGP=vSmDY4pAvBbS4_BCwOUyNTT5WA@mail.gmail.com>
 <171530.1765306357@localhost>
 <CADzfLwXp4c-MJx7yVDxAGNNxPbX4o9dqyivxavtHvmUsdXYqBQ@mail.gmail.com>
 <212153.1765654761@localhost>
In-Reply-To: <212153.1765654761@localhost>
From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Date: Thu, 18 Dec 2025 03:05:00 +0100
Message-ID: 
 <CADzfLwWm-6WpLiif3dUZ98jHH0D+z6b-PcDuez74Cpk6Gj8mmQ@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Antonin Houska <ah@cybertec.at>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>,
 Robert Treat <rob@xzilla.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CADzfLwWm-6WpLiif3dUZ98jHH0D%2Bz6b-PcDuez74Cpk6Gj8mmQ%40mail.gmail.com>
Precedence: bulk

Hello, Antonin!

On Sat, Dec 13, 2025 at 8:39=E2=80=AFPM Antonin Houska <ah@cybertec.at> wro=
te:
> > ---
> > > SpinLockAcquire(&shared->mutex);
> > > valid =3D shared->sfs_valid;
> > > SpinLockRelease(&shared->mutex);
> >
> > Better to remember last_exported here to avoid any races/misses.
>
> What races/misses exactly?

Just as some way to reduce a number of potential scenarios/states
between parallel actors.

> > ---
> > > bool       done;
> >
> > bool exit_after_lsn_upto?
>
> Not sure.

I think it should be named in some way to signal it is a request, not a rep=
ort.

> > Also, should we add some kind of back pressure between building
> > indexes/new heap and num of WAL we have?
> > But probably it is out of scope of the patch.
>
> Do you mean that the decoding worker should be less active if the amount =
of
> WAL doesn't grow too fast?

In the previous version (without background) we have some kind of
back-pressure during the scan part (if we have too muchWAL delayed
because of us - we process it).
But it is not more true with a background worker. At the same time -
it never was during the index building phase...

Best regards,
Mikhail.