| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6 |
| Date: | 2019-05-01 19:39:47 |
| Message-ID: | 20190501193947.iny6qngltwnaasgc@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2019-05-01 10:21:15 -0700, Andres Freund wrote:
> FWIW, the dirty-hack version (attached) of the CommandCounterIncrement()
> approach fixes the issue for a REINDEX pg_class_oid_index; in solation
> even when using CCA. Started a whole CCA testrun with it, but the
> results of that will obviously not be in quick.
Not finished yet, but it got pretty far:
parallel group (5 tests): create_index_spgist index_including_gist index_including create_view create_index
create_index ... ok 500586 ms
create_index_spgist ... ok 86890 ms
create_view ... ok 466512 ms
index_including ... ok 150279 ms
index_including_gist ... ok 109087 ms
test reindex_catalog ... ok 2285 ms
parallel group (16 tests): create_cast roleattributes drop_if_exists create_aggregate vacuum create_am hash_func select create_function_3 constraints typed_table rolenames errors updatable_views triggers inherit
that's where it's at right now:
parallel group (20 tests): init_privs security_label gin password drop_operator lock gist tablesample spgist
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2019-05-01 20:10:34 | pg_upgrade --clone error checking |
| Previous Message | Alvaro Herrera | 2019-05-01 19:21:24 | Re: Unhappy about API changes in the no-fsm-for-small-rels patch |