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 |
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. |
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 |