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

From Antonin Houska
Subject Re: why there is not VACUUM FULL CONCURRENTLY?
Date
Msg-id 49792.1741027227@localhost
Whole thread Raw
In response to Re: why there is not VACUUM FULL CONCURRENTLY?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> 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.

Thanks for explanation. The reason I failed to understand this was probably
that I tried to imagine something worse.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: bug when apply fast default mechanism for adding new column over domain with default value
Next
From: Matheus Alcantara
Date:
Subject: Re: RFC: Additional Directory for Extensions