From: Noah Misch <noah@leadboat.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: pgstatindex vs. !indisready
Date: Sun, 1 Oct 2023 18:31:26 -0700
Message-ID: <20231002013126.ad.nmisch@google.com> (raw)
In-Reply-To: <ZRoNwZD8gjGToV2R@paquier.xyz>
References: <20231001195309.a3@google.com>
<1867127.1696192645@sss.pgh.pa.us>
<20231001205830.2f.nmisch@google.com>
<CAH2-WzmFaz4RcJnyNrouHmf1x0FFTDFih_krm3aohVc3NmA9qQ@mail.gmail.com>
<ZRoNwZD8gjGToV2R@paquier.xyz>
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@leadboat.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?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, michael@paquier.xyz, pg@bowt.ie, tgl@sss.pgh.pa.us
Subject: Re: pgstatindex vs. !indisready
In-Reply-To: <20231002013126.ad.nmisch@google.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox