Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hK62r-0005g1-QV for pgsql-bugs@arkaria.postgresql.org; Fri, 26 Apr 2019 18:58:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hK62q-00083j-FQ for pgsql-bugs@arkaria.postgresql.org; Fri, 26 Apr 2019 18:58:00 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hK62q-00082d-2v for pgsql-bugs@lists.postgresql.org; Fri, 26 Apr 2019 18:58:00 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hK62n-0004Xv-FP for pgsql-bugs@lists.postgresql.org; Fri, 26 Apr 2019 18:57:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x3QIvnd4009944; Fri, 26 Apr 2019 14:57:49 -0400 From: Tom Lane To: Alvaro Herrera cc: Amit Langote , Amit Langote , Michael Paquier , jianingy.yang@gmail.com, PostgreSQL mailing lists , Pg Hackers Subject: Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping a partition table In-reply-to: <20190426153921.GA22956@alvherre.pgsql> References: <20190426153921.GA22956@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Fri, 26 Apr 2019 11:39:21 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9942.1556305069.1@sss.pgh.pa.us> Date: Fri, 26 Apr 2019 14:57:49 -0400 Message-ID: <9943.1556305069@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera writes: > Um, this one doesn't apply because of yesterday's 87259588d0ab. Before we spend too much time on minutiae, we should ask ourselves whether this patch is even going in the right direction. I'm not sure. One point is that if we simply adopt the old index as-is, we won't see any updates in its metadata. An example is that if we have an index on a varchar(10) column, and we alter the column to varchar(12), the current behavior is to generate a new index that agrees with that: regression=# create table pp(f1 varchar(10) unique); CREATE TABLE regression=# \d pp_f1_key Index "public.pp_f1_key" Column | Type | Key? | Definition --------+-----------------------+------+------------ f1 | character varying(10) | yes | f1 unique, btree, for table "public.pp" regression=# alter table pp alter column f1 type varchar(12); ALTER TABLE regression=# \d pp_f1_key Index "public.pp_f1_key" Column | Type | Key? | Definition --------+-----------------------+------+------------ f1 | character varying(12) | yes | f1 unique, btree, for table "public.pp" With this patch, I believe, the index column will still claim to be varchar(10). Is that OK? It might not actually break anything right now, but at the very least it's likely to be confusing. Also, it'd essentially render the declared types/typmods of index columns untrustworthy, which seems like something that would come back to bite us. regards, tom lane