Re: why there is not VACUUM FULL CONCURRENTLY?

Antonin Houska <ah@cybertec.at> wrote:

> Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> > On 2025-Mar-22, Antonin Houska wrote:
> > 
> > > Alvaro Herrera <alvherre@alvh.no-ip.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