Re: Injection points: some tools to wait and wake

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

In response to

Responses

Browse pgsql-hackers by date

  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