| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Matthijs van der Vleuten <postgresql(at)zr40(dot)nl>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable |
| Date: | 2021-10-19 14:40:04 |
| Message-ID: | 34B9319E-8FF3-4303-A94D-BCDBCDC7ED2C@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On 10/18/21, 11:49 PM, "Matthijs van der Vleuten" <postgresql(at)zr40(dot)nl> wrote:
> The test case doesn't seem entirely correct to me? The index being
> dropped (btree_tall_tbl_idx2) doesn't exist.
This was fixed before it was committed [0].
> Also, I don't believe this tests the case of dropping the index when
> it previously has been altered in this way.
That can still fail with the "has no options" ERROR, and fixing it
will still require a manual catalog update. The ERROR is actually
coming from the call to index_open(), so bypassing it might require
some rather intrusive changes. Given that it took over a year for
this bug to be reported, I suspect it might be more trouble than it's
worth.
Nathan
[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=fdd8857
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-10-19 15:38:21 | Re: BUG #17236: Postgres core on pstate->p_multiassign_exprs |
| Previous Message | Markus Zucker | 2021-10-19 12:57:17 | v14.0 segfaults on certain memoize query plans |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bossart, Nathan | 2021-10-19 14:50:14 | Re: .ready and .done files considered harmful |
| Previous Message | Magnus Hagander | 2021-10-19 14:19:04 | Re: parallelizing the archiver |