Re: Injection point locking

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

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-07-08 14:37:04 Re: 回复:Re: 回复:Re: speed up pg_upgrade with large number of tables
Previous Message feichanghong 2024-07-08 14:17:09 Re: Optimize commit performance with a large number of 'on commit delete rows' temp tables