| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pgstatindex vs. !indisready |
| Date: | 2023-10-02 01:31:26 |
| Message-ID: | 20231002013126.ad.nmisch@google.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 02, 2023 at 09:24:33AM +0900, Michael Paquier wrote:
> On Sun, Oct 01, 2023 at 04:20:42PM -0700, Peter Geoghegan wrote:
> > On Sun, Oct 1, 2023 at 2:00 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> >> [brin_desummarize_range brin_summarize_new_values brin_summarize_range
> >> gin_clean_pending_list] currently succeed. I propose to make them emit a
> >> DEBUG1 message and return early, like amcheck does, except on !indisready.
> >> This would allow users to continue running them on all indexes of the
> >> applicable access method. Doing these operations on an
> >> indisready&&!indisvalid index is entirely reasonable, since they relate to
> >> INSERT/UPDATE/DELETE operations.
>
> Hmm. Still slightly incorrect in some cases? Before being switched
> to indisvalid, an index built concurrently may miss some tuples
> deleted before the reference snapshot used to build the index was
> taken.
The !indisvalid index may be missing tuples, yes. In what way does that make
one of those four operations incorrect?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2023-10-02 02:48:20 | Re: document the need to analyze partitioned tables |
| Previous Message | Peter Geoghegan | 2023-10-02 00:44:29 | Re: pgstatindex vs. !indisready |