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