Re: pgstatindex vs. !indisready

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: pgstatindex vs. !indisready
Дата
Msg-id 20231022210245.2f.nmisch@google.com
обсуждение исходный текст
Ответ на Re: pgstatindex vs. !indisready  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pgstatindex vs. !indisready  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Wed, Oct 04, 2023 at 09:00:23AM +0900, Michael Paquier wrote:
> On Sun, Oct 01, 2023 at 06:31:26PM -0700, Noah Misch wrote:
> > The !indisvalid index may be missing tuples, yes.  In what way does that make
> > one of those four operations incorrect?
> 
> Reminding myself of what these four do, it looks that you're right and
> that the state of indisvalid is not going to change what they report.
> 
> Still, I'd like to agree with Tom's point to be more conservative and
> check also for indisvalid which is what the planner does.  These
> functions will be used in SELECTs, and one thing that worries me is
> that checks based on indisready may get copy-pasted somewhere else,
> leading to incorrect results where they get copied.  (indisready &&
> !indisvalid) is a "short"-term combination in a concurrent build
> process, as well (depends on how long one waits for the old snapshots
> before switching indisvalid, but that's way shorter than the period of
> time where the built indexes remain valid).

Neither choice would harm the user experience in an important way, so I've
followed your preference in the attached patch.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Guiding principle for dropping LLVM versions?
Следующее
От: jian he
Дата:
Сообщение: Re: UniqueKey v2