On Tue, Jun 18, 2024 at 08:23:49AM -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> > On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > > > > https://postgr.es/m/20240512232923.aa.nmisch@google.com wrote:
> > > > > > Separable, nontrivial things not fixed in the attached patch stack:
> > > > > >
> > > > > > - Inplace update uses transactional CacheInvalidateHeapTuple(). ROLLBACK of
> > > > > > CREATE INDEX wrongly discards the inval, leading to the relhasindex=t loss
> > > > > > still seen in inplace-inval.spec. CacheInvalidateRelmap() does this right.
> > > > >
> > > > > I plan to fix that like CacheInvalidateRelmap(): send the inval immediately,
> > > > > inside the critical section. Send it in heap_xlog_inplace(), too.
> >
> > I'm worried this might cause its own set of bugs, e.g. if there are any places
> > that, possibly accidentally, rely on the invalidation from the inplace update
> > to also cover separate changes.
>
> Good point. I do have index_update_stats() still doing an ideally-superfluous
> relcache update for that reason. Taking that further, it would be cheap
> insurance to have the inplace update do a transactional inval in addition to
> its immediate inval. Future master-only work could remove the transactional
> one. How about that?
Restoring the transactional inval seemed good to me, so I've rebased and
included that. This applies on top of three patches from
https://postgr.es/m/20240822073200.4f.nmisch@google.com. I'm attaching those
to placate cfbot, but this thread is for review of the last patch only.