Re: Injection point locking

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Injection point locking
Date: 2024-07-09 04:14:53
Message-ID: Zoy5PWAO8MtrmR-J@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 08, 2024 at 10:17:49AM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> Note that until we actually add an injection point to a function that
>> runs in the postmaster, there's no risk. If we're uneasy about that, we
>> could add an assertion to InjectionPointRun() to prevent it from running
>> in the postmaster, so that we don't cross that line inadvertently.

AFAIU, you want to be able to do that to enforce some protocol checks.
That's a fine goal.

> As long as we consider injection points to be a debug/test feature
> only, I think it's a net positive that one can be set in the
> postmaster. I'd be considerably more uncomfortable if somebody
> wanted to do that in production, but maybe it'd be fine even then.

This is documented as a developer feature for tests, the docs are
clear about that.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-07-09 04:22:46 Re: Pgoutput not capturing the generated columns
Previous Message Nathan Bossart 2024-07-09 03:33:13 Re: optimizing pg_upgrade's once-in-each-database steps