From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Subject: | pg_stat_get_replication_slot() marked not strict, crashes |
Date: | 2022-03-26 21:24:32 |
Message-ID: | 20220326212432.s5n2maw6kugnpyxw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-03-26 21:26:29 | Re: More weird compiler warnings |
Previous Message | Tom Lane | 2022-03-26 21:19:43 | Re: Why is lorikeet so unstable in v14 branch only? |