| From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| Date: | 2021-10-06 21:27:54 |
| Message-ID: | CALT9ZEFvdAcUp5JYNMRUgkDUtSkrToHNDxb8=jH4Eh5Cm+5=jQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
>
>
> It is the most consistent with the general design of the system, for
> reasons that are pretty deeply baked into the system. I'm reminded of
> the fact that REINDEX CONCURRENTLY's completion became blocked due to
> similar trepidations. Understandably so.
I may mistake, but I recall the fact that all indexes builds started during
some other (long) index build do not finish with indexes usable for selects
until that long index is built. This may and may not be a source of amcheck
misbehavior. Just a note what could be possibly considered.
Best regards,
Pavel Borisov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2021-10-06 21:45:49 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| Previous Message | Peter Geoghegan | 2021-10-06 20:49:12 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2021-10-06 21:45:49 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| Previous Message | Zhihong Yu | 2021-10-06 21:03:02 | Re: using extended statistics to improve join estimates |