Feedback-ID: ia2694551:Fastmail
Date: Mon, 3 Mar 2025 19:07:00 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Antonin Houska <ah@cybertec.at>
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?
Message-ID: <202503031807.dnacvpgnjkz7@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <127361.1740559688@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/202503031807.dnacvpgnjkz7%40alvherre.pgsql>
Precedence: bulk

On 2025-Feb-26, Antonin Houska wrote:

> @@ -403,39 +381,38 @@ cluster_rel(Relation OldHeap, Oid indexOid, ClusterParams *params)
>  	 * would work in most respects, but the index would only get marked as
>  	 * indisclustered in the current database, leading to unexpected behavior
>  	 * if CLUSTER were later invoked in another database.
> +	 *
> +	 * REPACK does not set indisclustered. XXX Not sure I understand the
> +	 * comment above: how can an attribute be set "only in the current
> +	 * database"?
>  	 */

Regarding this XXX comment, what's going on here is this: a CLUSTER
command needs to remember the index that a table is clustered on.  We
keep track of this in pg_index.indisclustered.  But pg_index is a local
relation, not shared across databases -- so the current CLUSTER command
can effect the update on the current database's pg_index only, not on
other databases.  So if the user were to run CLUSTER on one database
specifying an index, then connect to another one and expect CLUSTER
without specifying an index to honor the previously specified index,
that would not work.  Naturally this is only a problem for shared
catalogs.  Not being able to handle this for shared catalogs is not a
big loss.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/