Re: why there is not VACUUM FULL CONCURRENTLY? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: why there is not VACUUM FULL CONCURRENTLY?
Date
Msg-id CA+TgmobtxK1sNDULBJjNRF3bb3NPA_kwQK=ZctUf3i-3gkt1Sw@mail.gmail.com
Whole thread Raw
In response to Re: why there is not VACUUM FULL CONCURRENTLY?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: why there is not VACUUM FULL CONCURRENTLY?
List pgsql-hackers
On Thu, Mar 20, 2025 at 1:32 PM 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 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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?
Next
From: Joe Conway
Date:
Subject: Re: Support "make check" for PGXS extensions