Re: Inval reliability, especially for inplace updates - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Inval reliability, especially for inplace updates
Date
Msg-id 20250510151423.c2.nmisch@google.com
Whole thread Raw
In response to Re: Inval reliability, especially for inplace updates  (Nitin Motiani <nitinmotiani@google.com>)
List pgsql-hackers
On Sun, Nov 03, 2024 at 10:29:25AM -0800, Noah Misch wrote:
> On Fri, Nov 01, 2024 at 04:38:29PM -0700, Noah Misch wrote:
> > This was a near miss to having a worst-in-years regression in a minor release,
> > so I'm proposing this sequence:
> > 
> > - Revert from non-master branches commits 8e7e672 (inplace180, "WAL-log
> >   inplace update before revealing it to other sessions.") and 243e9b4
> >   (inplace160, "For inplace update, send nontransactional invalidations.").
> > 
> > - Back-patch inplace230-index_update_stats-io-before-buflock to harden commit
> >   a07e03f (inplace110, "Fix data loss at inplace update after heap_update()").
> > 
> > - Push attached inplace240 to master.
> > 
> > - Make the commitfest entry a request for review of v17 inplace160+inplace240.
> >   After some amount of additional review and master bake time, the reverted
> >   patches would return to non-master branches.

> Pushed as 0bada39.

> I'm attaching the v17 patch that now becomes the commitfest submission

That still applies cleanly.  I'm adding a back-patch of commit f4ece89, which
adds assertions intended to build confidence about the main patch.  The
commitfest entry requests a review of the first patch only, but the second
patch may answer questions that a review of the first would otherwise raise.

Attachment

pgsql-hackers by date:

Previous
From: Stepan Neretin
Date:
Subject: Re: Suggestion to add --continue-client-on-abort option to pgbench
Next
From: Stepan Neretin
Date:
Subject: Re: Accessing an invalid pointer in BufferManagerRelation structure