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 202503031807.dnacvpgnjkz7@alvherre.pgsql
Whole thread Raw
In response to Re: why there is not VACUUM FULL CONCURRENTLY?  (Antonin Houska <ah@cybertec.at>)
Responses Re: why there is not VACUUM FULL CONCURRENTLY?
List pgsql-hackers
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/



pgsql-hackers by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: making EXPLAIN extensible
Next
From: Andres Freund
Date:
Subject: Re: Improve monitoring of shared memory allocations