Content-Type: multipart/mixed; boundary="------------vvZscuR62zdKfMqkyGEltQAu"
Message-ID: <d92f0eca-bb14-4b8c-9fb0-3b79635e1a64@iki.fi>
Date: Tue, 9 Dec 2025 15:24:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgsql: injection_points: Remove portions related to custom
 pgstats
To: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>,
 pgsql-committers@lists.postgresql.org, Sami Imseih <samimseih@gmail.com>
References: <E1vSSCn-003N0Z-2i@gemulon.postgresql.org>
 <2899652.1765167313@sss.pgh.pa.us> <aTZZzFhQTtUKWGLm@paquier.xyz>
 <2904427.1765169854@sss.pgh.pa.us> <aTaPKpYufxut5Zs1@paquier.xyz>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <aTaPKpYufxut5Zs1@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/d92f0eca-bb14-4b8c-9fb0-3b79635e1a64%40iki.fi>
Precedence: bulk

This is a multi-part message in MIME format.
--------------vvZscuR62zdKfMqkyGEltQAu
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 08/12/2025 10:41, Michael Paquier wrote:
> On Sun, Dec 07, 2025 at 11:57:34PM -0500, Tom Lane wrote:
>> Nah, hold off till we have a discussion about whether the test is
>> correct to expect compatibility.  We can afford to have a couple
>> of BF animals unhappy for a day or two while we come to a decision.
> 
> By the way, while looking at the buildfarm failures, I have noticed
> that something is wrong in my patch.  Looking Makefile.global.in,
> USE_MODULE_DB is built based on REGRESS for the tests of
> src/test/modules/gin/.  However things are inconsistent between meson
> and ./configure.
> 
> For example, this host uses configure/make:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skimmer&dt=2025-12-08%2006%3A08%3A23
> 
> The database name is contrib_regression_gin_incomplete_splits, which
> points to the test gin_incomplete_split in src/test/modules/gin/,
> meaning that my patch would not work.
> 
> In the meson case, we got this failure:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2025-12-08%2006%3A27%3A04
> And here, the database name is regression_gin.
> 
> When I looked at the buildfarm failures, I saw the regression_gin
> first, wrote a patch based on that.  But the second one based on
> contrib_regression_gin_incomplete_splits was really puzzling me, until
> I've noticed that the difference was configure vs meson for the two
> hosts.  So it seems to me that we have a second issue here, where
> meson relies on a "name" while configure uses the first value of
> "REGRESS".  AdjustUpgrade.pm cannot know that it's dealing with one
> build method or the other.  In order to make my previous patch work,
> we could use a DROP DATABASE IF EXISTS on both database names.  That
> would work, but that feels grotty for the purpose of fixing things,
> especially as I don't see a point in keeping the test libraries across
> major upgrades..

Hmm, using the first value of REGRESS is surprising. How about we change 
the autoconf logic to match what meson does? As attached.

In the meson scripts, you can specify the database name explicitly by 
setting 'dbname'. It's only used in a few subdirs though.

This in src/test/interfaces/ecpg/test/meson.build looks weird:

>     'dbname': 'ecpg1_regression,ecpg2_regression',

As far as I can tell, dbname is not a list, so I don't understand how 
that works.

- Heikki

--------------vvZscuR62zdKfMqkyGEltQAu
Content-Type: text/x-patch; charset=UTF-8;
 name="derive-regression-db-name-like-meson-does.patch"
Content-Disposition: attachment;
 filename="derive-regression-db-name-like-meson-does.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9NYWtlZmlsZS5nbG9iYWwuaW4gYi9zcmMvTWFrZWZpbGUuZ2xv
YmFsLmluCmluZGV4IDM3MWNkN2ViYTJjLi5jNmYwZTFlYjVlMSAxMDA2NDQKLS0tIGEvc3Jj
L01ha2VmaWxlLmdsb2JhbC5pbgorKysgYi9zcmMvTWFrZWZpbGUuZ2xvYmFsLmluCkBAIC02
NzEsMTggKzY3MSw4IEBAIGVuZGlmCiAKIGlmbmVxICgkKFVTRV9NT0RVTEVfREIpLCkKICAg
UExfVEVTVERCID0gcGxfcmVncmVzc2lvbl8kKE5BTUUpCi0gIGlmbmVxICgkKE1PRFVMRV9i
aWcpLCkKLSAgICBDT05UUklCX1RFU1REQj1jb250cmliX3JlZ3Jlc3Npb25fJChNT0RVTEVf
YmlnKQotICAgIElTT0xBVElPTl9URVNUREI9aXNvbGF0aW9uX3JlZ3Jlc3Npb25fJChNT0RV
TEVfYmlnKQotICBlbHNlCi0gICAgaWZuZXEgKCQoTU9EVUxFUyksKQotICAgICAgQ09OVFJJ
Ql9URVNUREI9Y29udHJpYl9yZWdyZXNzaW9uXyQod29yZCAxLCQoTU9EVUxFUykpCi0gICAg
ICBJU09MQVRJT05fVEVTVERCPWlzb2xhdGlvbl9yZWdyZXNzaW9uXyQod29yZCAxLCQoTU9E
VUxFUykpCi0gICAgZWxzZQotICAgICAgQ09OVFJJQl9URVNUREI9Y29udHJpYl9yZWdyZXNz
aW9uXyQod29yZCAxLCQoUkVHUkVTUykpCi0gICAgICBJU09MQVRJT05fVEVTVERCPWlzb2xh
dGlvbl9yZWdyZXNzaW9uXyQod29yZCAxLCQoSVNPTEFUSU9OKSkKLSAgICBlbmRpZgotICBl
bmRpZgorICBDT05UUklCX1RFU1REQj1jb250cmliX3JlZ3Jlc3Npb25fJChub3RkaXIgJChz
dWJkaXIpKQorICBJU09MQVRJT05fVEVTVERCPWlzb2xhdGlvbl9yZWdyZXNzaW9uXyQobm90
ZGlyICQoc3ViZGlyKSkKIGVsc2UKICAgUExfVEVTVERCID0gcGxfcmVncmVzc2lvbgogICBD
T05UUklCX1RFU1REQiA9IGNvbnRyaWJfcmVncmVzc2lvbgo=

--------------vvZscuR62zdKfMqkyGEltQAu--