Re: why there is not VACUUM FULL CONCURRENTLY?

On Thu, Mar 20, 2025 at 1:32 PM 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 did look at 0002 again (and renamed the members of the new struct by
> adding a p_ prefix, as well as fixing the references to the old names
> that were in a few code comments here and there; I don't think these
> changes are "substantive"), and ended up wondering why do we need that
> change in the first place. According to the comment where the progress
> restore function is called, it's because reorderbuffer.c uses a
> subtransaction internally. But I went to look at reorderbuffer.c and
> noticed that the subtransaction is only used "when using the SQL
> function interface, because that creates a transaction already". So
> maybe we should look into making REPACK use reorderbuffer without having
> to open a transaction block.
>
> I didn't do anything about that, in particular I didn't actually try to
> run REPACK to see whether the transaction is needed. I'll be looking at
> that in the next couple of days.

Is there a README or a long comment in here someplace that is a good
place to read to understand the overall design of this feature?

--
Robert Haas
EDB: http://www.enterprisedb.com