Re: ALTER tbl rewrite loses CLUSTER ON index - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: ALTER tbl rewrite loses CLUSTER ON index
Date
Msg-id 20200403065438.GA78887@paquier.xyz
Whole thread Raw
In response to Re: ALTER tbl rewrite loses CLUSTER ON index  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: ALTER tbl rewrite loses CLUSTER ON index
List pgsql-hackers
On Thu, Apr 02, 2020 at 04:38:36AM -0300, Alvaro Herrera wrote:
> I don't think we need to worry about that problem, because we already
> checked that the pg_class tuple for the index is there two lines above.
> The pg_index tuple cannot have gone away on its own; and the index can't
> be deleted either, because cluster_rel holds AEL on the table.  There
> isn't "probably" about the can't-happen condition, is there?

Yes, you are right here.  I was wondering about an interference with
the multi-relation cluster that would not lock the parent relation at
the upper level of cluster() but the check on the existence of the
index makes sure that we'll never see an invalid entry in pg_index, so
let's keep patch 0002 as originally presented.  As the commit tree is
going to be rather crowded until feature freeze on Sunday, I'll wait
until Monday or Tuesday to finalize this patch set.

Now, would it be better to apply the refactoring patch for HEAD before
feature freeze, or are people fine if this is committed a bit after?
Patch 0002 is neither a new feature, nor an actual bug, and just some
code cleanup, but I am a bit worried about applying that cleanup on
HEAD just after the freeze.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: User Interface for WAL usage data
Next
From: "David G. Johnston"
Date:
Subject: Re: Syntax rules for a text value inside the literal for a user-defined type—doc section “8.16.2. Constructing Composite Values”