On Thu, Jun 13, 2024 at 05:35:49PM -0700, Noah Misch wrote:
> On Mon, Jun 10, 2024 at 07:45:25PM -0700, Noah Misch wrote:
> > On Thu, Jun 06, 2024 at 09:48:51AM -0400, Robert Haas wrote:
> > > It's not this patch set's fault, but I'm not very pleased to see that
> > > the injection point wait events have been shoehorned into the
> > > "Extension" category
> >
> > I've replied on that branch of the thread.
>
> I think the attached covers all comments to date. I gave everything v3, but
> most patches have just a no-conflict rebase vs. v2. The exceptions are
> inplace031-inj-wait-event (implements the holding from that branch of the
> thread) and inplace050-tests-inj (updated to cooperate with inplace031). Much
> of inplace031-inj-wait-event is essentially s/Extension/Custom/ for the
> infrastructure common to the two custom wait event types.
Starting 2024-06-27, I'd like to push
inplace080-catcache-detoast-inplace-stale and earlier patches, self-certifying
them if needed. Then I'll submit the last three to the commitfest. Does
anyone want me to delay that step?
Two more test-related changes compared to v3:
- In inplace010-tests, add to 027_stream_regress.pl a test that catalog
contents match between primary and standby. If one of these patches broke
replay of inplace updates, this would help catch it.
- In inplace031-inj-wait-event, make sysviews.sql indifferent to whether
InjectionPoint wait events exist. installcheck need this if other activity
created such an event since the last postmaster restart.
