Re: why there is not VACUUM FULL CONCURRENTLY?

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.

Thanks.

> 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.

Which part of reorderbuffer.c do you mean? ISTM that the use of subransactions
is more extensive. At least ReorderBufferImmediateInvalidation() appears to
rely on it, which in turn is called by xact_decode().

(I don't claim that saving and restoring the progress state is perfect, but I
don't have better idea right now.)

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