Re: Adding REPACK [concurrently]

From: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>
Subject: Re: Adding REPACK [concurrently]
Date: 2025-12-18 02:05:00
Message-ID: CADzfLwWm-6WpLiif3dUZ98jHH0D+z6b-PcDuez74Cpk6Gj8mmQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, Antonin!

On Sat, Dec 13, 2025 at 8:39 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> > ---
> > > SpinLockAcquire(&shared->mutex);
> > > valid = 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 report.

> > 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-12-18 02:25:45 Re: Report bytes and transactions actually sent downtream
Previous Message Mihail Nikalayeu 2025-12-18 01:47:00 Re: Adding REPACK [concurrently]