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

From Amit Langote
Subject Re: ALTER tbl rewrite loses CLUSTER ON index
Date
Msg-id CA+HiwqEOyeHaJtz9rD0B_hhvWW4-zcF+edYi+Kes_oAXRPbN6w@mail.gmail.com
Whole thread Raw
In response to Re: ALTER tbl rewrite loses CLUSTER ON index  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER tbl rewrite loses CLUSTER ON index  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Fri, Mar 13, 2020 at 2:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Justin Pryzby <pryzby@telsasoft.com> writes:
> > @cfbot: resending with only Amit's 0001, since Michael pushed a variation on
> > 0002.

Thank you for taking a look at it.

> Boy, I really dislike this patch.  ATPostAlterTypeParse is documented as
> using the supplied definition string, and nothing else, to reconstruct
> the index.  This breaks that without even the courtesy of documenting
> the breakage.  Moreover, the reason why it's designed like that is to
> avoid requiring the old index objects to still be accessible.  So I'm
> surprised that this hack works at all.  I don't think it would have
> worked at the time the code was first written, and I think it's imposing
> a constraint we'll have problems with (again?) in future.

Okay, so maybe in the middle of ATPostAlterTypeParse() is not a place
to do it, but don't these arguments apply to
RebuildConstraintComment(), which I based the patch on?

> The right way to fix this is to note the presence of the indisclustered
> flag when we're examining the index earlier, and include a suitable
> command in the definition string.  So probably pg_get_indexdef_string()
> is what needs to change.  It doesn't look like that's used anywhere
> else, so we can just redefine its behavior as needed.

I came across a commit that recently went in:

commit 1cc9c2412cc9a2fbe6a381170097d315fd40ccca
Author: Peter Eisentraut <peter@eisentraut.org>
Date:   Fri Mar 13 11:28:11 2020 +0100

    Preserve replica identity index across ALTER TABLE rewrite

which fixes something very similar to what we are trying to with this
patch.  The way it's done looks to me very close to what you are
telling.  I have updated the patch to be similar to the above fix.

--
Thank you,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Kuntal Ghosh
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Next
From: Masahiko Sawada
Date:
Subject: Re: Internal key management system