Re: pg_stat_reset() weirdness

Tom Lane wrote:
> 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:

I guess I should know better than to jump to a conclusion. But I *was* 
under the impression we were supposed to use the unused_oids script to 
get a unique oid for a new function.


> -- 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.
> 

Actually, I don't see the regression failure here at all, now that I try 
the patch.

Joe