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
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 |