Re: pgstatindex vs. !indisready - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: pgstatindex vs. !indisready
Date
Msg-id CAH2-WzmPtaWC8bpVwrm7sDikgHHQ2_msTR0VVHR7c8p6J+G9Vg@mail.gmail.com
Whole thread Raw
In response to Re: pgstatindex vs. !indisready  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pgstatindex vs. !indisready
Next
From: Noah Misch
Date:
Subject: Re: pgstatindex vs. !indisready