From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Marcos Pegoraro <marcos@f10.com.br>, Michael Banck <mbanck@gmx.net>,
    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>
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?
In-reply-to: <6059.1743060030@localhost>
References: <202503251432.o6obtgywjow5@alvherre.pgsql>
 <6059.1743060030@localhost>
Comments: In-reply-to Antonin Houska <ah@cybertec.at>
   message dated "Thu, 27 Mar 2025 08:20:30 +0100."
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Date: Mon, 31 Mar 2025 16:26:25 +0200
Message-ID: <104580.1743431185@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/104580.1743431185%40localhost>
Precedence: bulk

--=-=-=
Content-Type: text/plain

Antonin Houska <ah@cybertec.at> wrote:

> Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> > On 2025-Mar-22, Antonin Houska wrote:
> > 
> > > 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 rebased again, fixing a compiler warning reported by CI and applying
> > pgindent to each individual patch.  I'm slowly starting to become more
> > familiar with the whole of this new code.
> 
> I'm trying to reflect Robert's suggestions about locking [1]. The next version
> should be a bit simpler, so maybe wait for it before you continue studying the
> code.

This is it. A few notes:

* Since there's no unlocking during the processing now, the code to check for
  catalog changes was removed.

* Some code moved from 0004 to 0005, where it fits better. (Also the commit
  messages of these two parts elaborated a bit more.)

* Regarding the progress monitoring, I do in 0004 what I proposed in [1]:
  BeginInternalSubTransaction() now sets a flag that avoids clearing of the
  progress state in AbortSubTransaction()

* Although I consider 0005 (Preserve visibility information of the concurrent
  data changes.) important, it occurs to me now that it might introduce quite
  some overhead.

* 0003 is new in the series. I thought it'll be needed, then I realized it's
  not. It might be useful as refactoring though. Please let me know if I
  should maintain it or drop it.

[1] https://www.postgresql.org/message-id/80297.1742989179%40localhost

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


--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment; filename=v11-0001-Add-REPACK-command.patch