Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping a partition table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Amit Langote <amitlangote09(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, jianingy(dot)yang(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping a partition table
Date: 2019-04-26 18:57:49
Message-ID: 9943.1556305069@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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). 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-04-26 21:21:46 Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping a partition table
Previous Message Tom Lane 2019-04-26 17:10:00 Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)

Browse pgsql-hackers by date

  From Date Subject
Next Message Souvik Bhattacherjee 2019-04-26 18:58:20 Initializing LWLock Array from Server Code
Previous Message Justin Pryzby 2019-04-26 17:17:22 Re: clean up docs for v12