| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: why is pg_upgrade's regression run so slow? |
| Date: | 2024-08-20 13:31:14 |
| Message-ID: | 84aa00ab-09d5-4ae6-baff-e37ca7adcae4@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2024-08-19 Mo 8:00 AM, Alexander Lakhin wrote:
> Hello Andrew,
>
> 29.07.2024 13:54, Andrew Dunstan wrote:
>>
>> On 2024-07-29 Mo 4:00 AM, Alexander Lakhin wrote:
>>>
>>> And another interesting fact is that TEMP_CONFIG is apparently
>>> ignored by
>>> `meson test regress/regress`. For example, with temp.config containing
>>> invalid settings, `meson test pg_upgrade/002_pg_upgrade` fails, but
>>> `meson test regress/regress` passes just fine.
>>>
>>>
>>
>> Well, that last fact explains the discrepancy I originally complained
>> about. How the heck did that happen? It looks like we just ignored
>> its use in Makefile.global.in :-(
>
> Please look at the attached patch (partially based on ideas from [1]) for
> meson.build, that aligns it with `make` in regard to use of TEMP_CONFIG.
>
> Maybe it could be implemented via a separate meson option, but that would
> also require modifying at least the buildfarm client...
>
> [1]
> https://www.postgresql.org/message-id/CAN55FZ304Kp%2B510-iU5-Nx6hh32ny9jgGn%2BOB5uqPExEMK1gQQ%40mail.gmail.com
>
>
I think this is the way to go. The patch LGTM.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2024-08-20 13:46:54 | Re: Some questions about PostgreSQL’s design. |
| Previous Message | Amit Langote | 2024-08-20 13:14:58 | Re: generic plans and "initial" pruning |