pg_stat_get_replication_slot() marked not strict, crashes - Mailing list pgsql-hackers

From Andres Freund
Subject pg_stat_get_replication_slot() marked not strict, crashes
Date
Msg-id 20220326212432.s5n2maw6kugnpyxw@alap3.anarazel.de
Whole thread Raw
Responses Re: pg_stat_get_replication_slot() marked not strict, crashes  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_stat_get_replication_slot() marked not strict, crashes  (vignesh C <vignesh21@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is lorikeet so unstable in v14 branch only?
Next
From: Andres Freund
Date:
Subject: Re: More weird compiler warnings