Re: Adding REPACK [concurrently]
| От | Mihail Nikalayeu |
|---|---|
| Тема | Re: Adding REPACK [concurrently] |
| Дата | |
| Msg-id | CADzfLwWm-6WpLiif3dUZ98jHH0D+z6b-PcDuez74Cpk6Gj8mmQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Adding REPACK [concurrently] (Antonin Houska <ah@cybertec.at>) |
| Список | pgsql-hackers |
Hello, Antonin! On Sat, Dec 13, 2025 at 8:39 PM Antonin Houska <ah@cybertec.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.
В списке pgsql-hackers по дате отправления: