Hi, On 2018-08-02 13:00:16 -0700, Peter Geoghegan wrote: > On Tue, Jul 31, 2018 at 9:00 PM, Andres Freund <andres@xxxxxxxxxxx> wrote: > > I don't think that's particularly relevant. We should always register an > > invalidation before the relevant CommandCounterIncrement(), because that > > is what makes catalog changes visible, and therefore requires > > registering invalidations for coherency. > > Fair enough. How about the attached revision? Looks good to me, minus some optional nitpicks in the commit message below. > From 156be401c38f7884ed65641aa202b72b698f3e91 Mon Sep 17 00:00:00 2001 > From: Peter Geoghegan <pg@xxxxxxx> > Date: Tue, 31 Jul 2018 18:33:30 -0700 > Subject: [PATCH v2] Add table relcache invalidation to index builds. > > It's necessary to make sure that owning tables have a relcache > invalidation prior to advancing the command counter to make > newly-entered catalog tuples for the index visible. inval.c must be > able to roll back the local caches in the event of transaction abort. > There is only a problem when CREATE INDEX transactions abort, since > there is a generic invalidation once we reach index_update_stats(). s/roll back/maintain consistency of/. I'd also perhaps weaken the next sentence, by adding a 'practically' or such, as a memory allocation failure or such before the index build starts could cause this as well. Greetings, Andres Freund
