Re: pgstatindex vs. !indisready

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pgstatindex vs. !indisready
Дата
Msg-id CAH2-WzmPtaWC8bpVwrm7sDikgHHQ2_msTR0VVHR7c8p6J+G9Vg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgstatindex vs. !indisready  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Sun, Oct 1, 2023 at 5:24 PM Michael Paquier <michael@paquier.xyz> wrote:
> > FWIW, amcheck's handling of unlogged relations when in hot standby
> > mode is based on the following theory: if recovery were to end, the
> > index would become an empty index, so just treat it as if it was
> > already empty during recovery. Not everybody thought that this
> > behavior was ideal, but ISTM that it has fewer problems than any
> > alternative approach you can think of. The same argument works just as
> > well with any function that accepts a regclass argument IMV.
>
> It depends, I guess, on how "user-friendly" all that should be.  I
> have seen in the past as argument that it may be sometimes better to
> have a function do nothing rather than ERROR when these are used
> across a scan of pg_class, for example, particularly for non-SRFs.
> Even if sometimes errors can be bypassed with more quals on the
> relkind or such (aka less complicated queries with less JOINs to
> write).

I think of recovery as a property of the whole system. So throwing an
error about one particular unlogged index that the user (say) checked
during recovery doesn't seem sensible. After all, the answer that
RecoveryInProgress() gives can change in a way that's observable
within individual transactions.

Again, I wouldn't claim that this is very elegant. Just that it seems
to have the fewest problems.

--
Peter Geoghegan



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pgstatindex vs. !indisready
Следующее
От: Noah Misch
Дата:
Сообщение: Re: pgstatindex vs. !indisready