Re: pgsql: Prevent instability in contrib/pageinspect's regression test.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: pgsql: Prevent instability in contrib/pageinspect's regression test.
Date: 2022-11-21 19:12:49
Message-ID: 3258427.1669057969@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

I wrote:
> I'll check to see if any sibling functions have the same issue,
> and push a patch to adjust them.
> Presumably the parallel labeling has to be fixed as far back as
> it's marked that way (didn't look). Maybe we should push the
> test change further back too, just to exercise this.

Hmm, so this is easy enough to fix in HEAD and v15, as attached.
However, there's a problem in older branches: their newest
versions of pageinspect are older than 1.10, so this doesn't
work as-is.

We could imagine inventing versions like 1.9.1, and providing
a script pageinspect--1.9--1.9.1.sql to do what's done here
as well as (in later branches) pageinspect--1.9.1--1.10.sql that
duplicates pageinspect--1.9--1.10.sql, and then the same again for
1.8 and 1.7 for the older in-support branches. That seems like
an awful lot of trouble for something that there have been no
field complaints about.

I'm inclined to apply this in HEAD and v15, and revert the
test change in v14, and call it good.

regards, tom lane

Attachment Content-Type Size
fix-pageinspect-parallel-markings.patch text/x-diff 3.2 KB

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2022-11-21 19:56:28 Re: pgsql: Prevent instability in contrib/pageinspect's regression test.
Previous Message Tom Lane 2022-11-21 18:08:58 Re: pgsql: Prevent instability in contrib/pageinspect's regression test.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-11-21 19:15:18 Re: Re: Damage control for planner's get_actual_variable_endpoint() runaway
Previous Message Andres Freund 2022-11-21 19:09:52 Re: Damage control for planner's get_actual_variable_endpoint() runaway