Re: pg_stat_reset() weirdness

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Ah doh - I thought it was catching it returning a boolean.  I'll fix and
> resubmit.

Unfortunately I don't believe Joe's theory --- an OID conflict between
pg_proc and pg_type shouldn't matter, and in any case the particular
sanity check that's failing is not looking at pg_type:

-- Look for illegal values in pg_proc fields.
-- NOTE: currently there are a few pg_proc entries that have prorettype = 0.
-- Someday that ought to be cleaned up.
SELECT p1.oid, p1.proname
FROM pg_proc as p1
WHERE (p1.prolang = 0 OR p1.prorettype = 0 OR      p1.pronargs < 0 OR p1.pronargs > 16)AND p1.proname !~
'^pl[^_]+_call_handler$'ANDp1.proname !~ '^RI_FKey_'AND p1.proname !~ 'costestimate$'AND p1.proname !=
'update_pg_pwd_and_pg_group';

The pg_stat_reset definition I see in Chris' "round 3" patch does not
look like it should trigger this test.  (I had misremembered the
previous discussion to think that he'd set prorettype = 0, but he
didn't.)  So what's going wrong exactly?  It needs investigation.
        regards, tom lane