Re: why there is not VACUUM FULL CONCURRENTLY?

Antonin Houska <ah(at)cybertec(dot)at> wrote:

> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> > On 2025-Mar-22, Antonin Houska wrote:
> >
> > > Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > >
> > > > I rebased this patch series; here's v09. No substantive changes from v08.
> > > > I made sure the tree still compiles after each commit.
> >
> > I rebased again, fixing a compiler warning reported by CI and applying
> > pgindent to each individual patch. I'm slowly starting to become more
> > familiar with the whole of this new code.
>
> I'm trying to reflect Robert's suggestions about locking [1]. The next version
> should be a bit simpler, so maybe wait for it before you continue studying the
> code.

This is it. A few notes:

* Since there's no unlocking during the processing now, the code to check for
catalog changes was removed.

* Some code moved from 0004 to 0005, where it fits better. (Also the commit
messages of these two parts elaborated a bit more.)

* Regarding the progress monitoring, I do in 0004 what I proposed in [1]:
BeginInternalSubTransaction() now sets a flag that avoids clearing of the
progress state in AbortSubTransaction()

* Although I consider 0005 (Preserve visibility information of the concurrent
data changes.) important, it occurs to me now that it might introduce quite
some overhead.

* 0003 is new in the series. I thought it'll be needed, then I realized it's
not. It might be useful as refactoring though. Please let me know if I
should maintain it or drop it.

[1] https://www.postgresql.org/message-id/80297.1742989179%40localhost

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