Re: why there is not VACUUM FULL CONCURRENTLY?

Michael Banck <mbanck@gmx.net>

From: Michael Banck <mbanck@gmx.net>
To: Antonin Houska <ah@cybertec.at>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Junwang Zhao <zhjwpku@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-01-30T08:34:01Z
Lists: pgsql-hackers
Hi,

On Mon, Jan 13, 2025 at 02:48:31PM +0100, Antonin Houska wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > On 2025-Jan-09, Antonin Houska wrote:
> > > It seems you accidentally fixed another problem :-) I was referring to the
> > > 'lockmode' argument of make_new_heap(). I can try to write a patch for that
> > > but ...
> > > 
> > > > Meanwhile the patch 0004 has some seemingly trivial conflicts.  If you
> > > > want to rebase, I'd appreciate that.  In the meantime I'll give a look
> > > > at the next two other API changes.
> 
> This is the patch series rebased on top of the commit cc811f92ba.
> 
> I haven't addressed the problem of a new command yet - for that I'd like to
> see some sort of consensus, so that I do not have to do all the related
> changes many times.

Well, looks like this patch-set is blocked on the bikeshedding part?

Somebody should call a shot here, then.


Michael



Commits

  1. Add CONCURRENTLY option to REPACK

  2. Introduce the REPACK command

  3. Adjust signature of cluster_rel() and its subroutines

  4. Simplify signature of RewriteTable