Re: pgstatindex vs. !indisready
От
Tom Lane
Тема
Re: pgstatindex vs. !indisready
Дата
Msg-id
1867127.1696192645@sss.pgh.pa.us
Ответ на
pgstatindex vs. !indisready (Noah Misch)
Список
Дерево обсуждения
pgstatindex vs. !indisready Noah Misch <noah@leadboat.com>
Re: pgstatindex vs. !indisready Tom Lane <tgl@sss.pgh.pa.us>
Re: pgstatindex vs. !indisready Noah Misch <noah@leadboat.com>
Re: pgstatindex vs. !indisready Peter Geoghegan <pg@bowt.ie>
Re: pgstatindex vs. !indisready Michael Paquier <michael@paquier.xyz>
Re: pgstatindex vs. !indisready Noah Misch <noah@leadboat.com>
Re: pgstatindex vs. !indisready Michael Paquier <michael@paquier.xyz>
Re: pgstatindex vs. !indisready Noah Misch <noah@leadboat.com>
Re: pgstatindex vs. !indisready Michael Paquier <michael@paquier.xyz>
Re: pgstatindex vs. !indisready Peter Geoghegan <pg@bowt.ie>
Noah Misch writes: > Running pgstatindex on some !indisready indexes fails with "ERROR: XX001: > could not read block 0 in file". This reproduces it: > ... > Since XX001 = ERRCODE_DATA_CORRUPTED appears in the "can't-happen" class, it's > not a good fit for this scenario. I propose to have pgstatindex fail early on > !indisready indexes. +1 > We could go a step further and also fail on > indisready&&!indisvalid indexes, which are complete enough to accept inserts > but not complete enough to answer queries. I don't see a reason to do that, > but maybe someone else will. Hmm. Seems like the numbers pgstatindex would produce for a not-yet-complete index would be rather irrelevant, even if the case doesn't risk any outright problems. I'd be inclined to be conservative and insist on indisvalid being true too. regards, tom lane
В списке pgsql-hackers по дате отправления