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

From Alvaro Herrera
Subject Re: why there is not VACUUM FULL CONCURRENTLY?
Date
Msg-id 202501310932.ugw3k5c4orgv@alvherre.pgsql
Whole thread Raw
In response to why there is not VACUUM FULL CONCURRENTLY?  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: why there is not VACUUM FULL CONCURRENTLY?
List pgsql-hackers
On 2025-Jan-31, Antonin Houska wrote:

> I assume the patch should mark CLUSTER deprecated rather than removing it
> immediately.

Yeah, we should certainly not make any statements fail that work today.
Same goes for VACUUM FULL.

> I also agree that tables not being REPACKed should be treated as not being
> logically decoded, i.e. the logical decoding specific information should not
> be written to WAL for them. Neither time nor energy should be wasted :-)

Cool.

Something that Robert Haas just mentioned to me is handling of row
locks: if concurrent transactions are keeping rows in the original table
locked (especially SELECT FOR KEY SHARE, since that's not considered by
logical decoding at present and it would be possible to break foreign
keys if we just do nothing), them we need these to be "transferred" to
the new table somehow.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"¿Qué importan los años?  Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo"  (Mafalda)



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Use "protocol options" name instead of "protocol extensions" everywhere
Next
From: Laurenz Albe
Date:
Subject: Re: Use "protocol options" name instead of "protocol extensions" everywhere