From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Subject: | Re: Injection points: some tools to wait and wake |
Date: | 2024-03-04 22:23:15 |
Message-ID: | ZeZJ0yv5kmLlYAAN@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 04, 2024 at 10:51:41AM +0100, Jelte Fennema-Nio wrote:
> Yeah, it makes sense that you'd want to backport fixes/changes to
> this. As long as you put a disclaimer in the docs that you can do that
> for this module, I think it would be fine. Our tests fairly regularly
> break anyway when changing minor versions of postgres in our CI, e.g.
> due to improvements in the output of isolationtester. So if changes to
> this module require some changes that's fine by me. Seems much nicer
> than having to copy-paste the code.
In my experience, anybody who does serious testing with their product
integrated with Postgres have two or three types of builds with their
own scripts: one with assertions, -DG and other developer-oriented
options enabled, and one for production deployments with more
optimized options like -O2. Once there are custom scripts to build
and package Postgres, do we really need to move that to contrib/ at
all? make install would work for a test module as long as the command
is run locally in its directory.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-03-04 22:41:58 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Previous Message | Nathan Bossart | 2024-03-04 22:21:18 | Re: Popcount optimization using AVX512 |