Re: pg_stat_reset() weirdness

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)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$'
AND p1.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