| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, Петър Славов <pet(dot)slavov(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY |
| Date: | 2022-05-25 00:59:27 |
| Message-ID: | Yo1/b7QibuJS6hAP@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, May 24, 2022 at 03:24:33PM -0700, Andres Freund wrote:
> On 2022-05-24 17:11:12 -0400, Greg Stark wrote:
>> Aside from amcheck I wonder if we can come up with any way for users
>> to tell whether their index is affected or at risk. Like, is there a
>> way to tell from catalog entries if an index was created with CIC?
>
> Not reliably, afaik. indcheckxmin won't ever be set for a CIC index IIRC, but
> it's not reliably set for a non-CIC index.
When it comes to REINDEX, we recreate entirely a new relation for the
concurrent flavor, dropping the old one. Hence its OID changes, while
all the data from the old relation gets copied over. That's not much
and you cannot use that for a CIC, still..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-05-25 01:01:37 | Re: Use of signal-unsafe functions from signal handlers |
| Previous Message | Michael Paquier | 2022-05-25 00:51:42 | Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function |