Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping apartition table - Mailing list pgsql-bugs

From Amit Langote
Subject Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping apartition table
Date
Msg-id 3cf270d8-40dc-ea8b-c7b7-4236af6ef972@lab.ntt.co.jp
Whole thread Raw
In response to Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping a partition table  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On 2019/04/27 3:57, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> 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).

You're right, that's what happens.

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

That's definitely misleading.

Still, I think it'd be nice if we didn't have to do full-blown
DefineIndex() in this case if only to update the pg_attribute tuples of
the index relation.  Maybe we could update them directly in the ALTER
COLUMN TYPE's code path?

Thanks,
Amit




pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15793: Required Community Version Installs not the customized EnterpriseDB one.
Next
From: PG Bug reporting form
Date:
Subject: BUG #15794: Defects regarding stored procedure parameters