Date: Wed, 12 Aug 2020 12:00:06 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [BUG] Error in BRIN summarization
Message-ID: <20200812160006.GA24770@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAH2-Wz=eop3qZyL0DrsJnjnZA9ifSUKa4PsHekO=rEUfs0kFEg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Jul-28, Peter Geoghegan wrote:

> On Mon, Jul 27, 2020 at 10:25 AM Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > (I was also considering whether it needs to be a loop to reobtain root
> > tuples, in case a concurrent transaction can create a new item while
> > we're checking that item; but I don't think that can really happen for
> > one individual tuple.)
> 
> I wonder if something like that is the underlying problem in a recent
> problem case involving a "REINDEX index
> pg_class_tblspc_relfilenode_index" command that runs concurrently with
> the regression tests:
> 
> https://postgr.es/m/CAH2-WzmBxu4o=pMsniur+bwHqCGCmV_AOLkuK6BuU7ngA6evqw@mail.gmail.com
> 
> We see a violation of the HOT invariant in this case, though only for
> a system catalog index, and only in fairly particular circumstances
> involving concurrency.

Hmm.  As far as I understand, the bug Anastasia reports can only hit an
index build that occurs concurrently to heap updates; and that cannot
happen for a regular index build, only for CREATE INDEX CONCURRENTLY and
REINDEX CONCURRENTLY.  So unless I miss something, it's not related to
that other bug.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services