pg_stat_get_replication_slot() marked not strict, crashes
От | Andres Freund |
---|---|
Тема | pg_stat_get_replication_slot() marked not strict, crashes |
Дата | |
Msg-id | 20220326212432.s5n2maw6kugnpyxw@alap3.anarazel.de обсуждение исходный текст |
Ответы |
Re: pg_stat_get_replication_slot() marked not strict, crashes
Re: pg_stat_get_replication_slot() marked not strict, crashes |
Список | pgsql-hackers |
Hi, I'm working to increase the test coverage of pgstat related stuff higher (for the shared memory stats patch, of course). "Accidentally" noticed that SELECT * FROM pg_stat_get_replication_slot(NULL); crashes. This is present in HEAD and 14. I guess we'll have to add a code-level check in 14 to deal with this? pg_stat_get_subscription_stats() also is wrongly marked. But at least in the trivial cases just returns bogus results (for 0/InvalidOid). That's only in HEAD, so easy to deal with. The other functions returned by SELECT oid::regprocedure FROM pg_proc WHERE proname LIKE 'pg%stat%' AND pronargs > 0 AND NOT proisstrict; look ok. I wonder if we ought to make PG_GETARG_DATUM(n) assert that !PG_ARGISNULL(n)? That'd perhaps make it easier to catch some of these... It'd be nice to have a test in sanity check to just call each non-strict function with NULL inputs automatically. But the potential side-effects probably makes that not a realistic option? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: