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

From Kirill Reshke
Subject Re: why there is not VACUUM FULL CONCURRENTLY?
Date
Msg-id CALdSSPiqTX7UGtGoHO6+btNQ-zXd=ETwxC1J9kGBOtJGLkaFWA@mail.gmail.com
Whole thread Raw
In response to Re: why there is not VACUUM FULL CONCURRENTLY?  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers
On Fri, 2 Aug 2024 at 11:09, Antonin Houska <ah@cybertec.at> wrote:
>
> Kirill Reshke <reshkekirill@gmail.com> wrote:
> > However, in general, the 3rd patch is really big, very hard to
> > comprehend.  Please consider splitting this into smaller (and
> > reviewable) pieces.
>
> I'll try to move some preparation steps into separate diffs, but not sure if
> that will make the main diff much smaller. I prefer self-contained patches, as
> also explained in [3].

Thanks for sharing [3], it is a useful link.

There is actually one more case when ACCESS EXCLUSIVE is held: during
table rewrite (AT set TAM, AT set Tablespace and AT alter column type
are some examples).
This can be done CONCURRENTLY too, using the same logical replication
approach, or do I miss something?
I'm not saying we must do it immediately, this should be a separate
thread, but we can do some preparation work here.

I can see that a bunch of functions which are currently placed in
cluster.c can be moved to something like
logical_rewrite_heap.c. ConcurrentChange struct and
apply_concurrent_insert function  is one example of such.

So, if this is the case, 0003 patch can be splitted in two:
The first one is general utility code for logical table rewrite
The second one with actual VACUUM CONCURRENTLY feature.

What do you think?



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: Adding OLD/NEW support to RETURNING
Next
From: Steven Niu
Date:
Subject: Re: [Patch] remove duplicated smgrclose