Re: test_autovacuum/001_parallel_autovacuum is broken
| От | Michael Paquier |
|---|---|
| Тема | Re: test_autovacuum/001_parallel_autovacuum is broken |
| Дата | |
| Msg-id | adWcVrX3jrHPoCmD@paquier.xyz обсуждение |
| Ответ на | Re: test_autovacuum/001_parallel_autovacuum is broken (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: test_autovacuum/001_parallel_autovacuum is broken
|
| Список | pgsql-hackers |
On Tue, Apr 07, 2026 at 01:02:49PM -0500, Sami Imseih wrote: > Perhaps, but I don't see it being unreasonable for injection points. > > I guess we can also think about expanding InjectionPointCondition to > handle other types of conditions, maybe OID??, to filter when running > the point. Yeah, InjectionPointConditionType was designed with these types of extensions in mind in terms of conditions you want to assign to a point name when attaching it, with the check happening in the callback attached when it is run. It should not be complicated to extend injection_points_attach(), just pass down a string that it then translated to an OID, or you could use a different grammar as well. One thing that I'd be careful about is to handle that with one argument in the SQL attach function, with the condition data given as an input string. One grammar that Alexander K. designed at some point for some of the facilities he had proposed was a JSON input, but that's an implementation artifact. Doing something as a separate module/library would be also fine. We do that for the AIO tests. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: