Re: [HACKERS] pg_stat_reset() weirdness
Can I have the updated version of this? --- Christopher Kings-Lynne wrote: Ah doh - I thought it was catching it returning a boolean. I'll fix and resubmit. Chris - Original Message - From: Joe Conway [EMAIL PROTECTED] To: Christopher Kings-Lynne [EMAIL PROTECTED] Cc: Hackers [EMAIL PROTECTED] Sent: Friday, August 09, 2002 11:26 PM Subject: Re: [HACKERS] pg_stat_reset() weirdness Christopher Kings-Lynne wrote: Hi guys, If you apply the pg_stat_reset() function patch you get this regression failure. Is this because it's returning a bool I guess? Shall I just fix the regression test to exclude this function? AND p1.proname != 'update_pg_pwd_and_pg_group'; oid |proname ! --+--- ! 2249 | pg_stat_reset ! (1 row) Likely because this is now in CVS: DATA(insert OID = 2249 ( recordPGNSP PGUID 4 t p t \054 0 0 oidin oidout i p f 0 -1 0 _null_ _null_ )); #define RECORDOID 2249 The Oids conflict. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] pg_stat_reset() weirdness
Joe Conway [EMAIL PROTECTED] writes: 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. unique_oids script Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_stat_reset() weirdness
Christopher Kings-Lynne wrote: unique_oids script Look in src/include/catalog. You'll find duplicate_oids unused_oids shell scripts. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_stat_reset() weirdness
Hang on - I _can't_ fix the function defiition - it returns a bool and that's why it's failing. I can't have it returning a void because it's not possible. Check list of all other excluded functions as well... Chris - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Christopher Kings-Lynne [EMAIL PROTECTED] Cc: Hackers [EMAIL PROTECTED] Sent: Friday, August 09, 2002 9:50 PM Subject: Re: [HACKERS] pg_stat_reset() weirdness Christopher Kings-Lynne [EMAIL PROTECTED] writes: If you apply the pg_stat_reset() function patch you get this regression failure. Is this because it's returning a bool I guess? Shall I just fix the regression test to exclude this function? No, you should fix the function definition. The sanity checks are there for a reason. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_stat_reset() weirdness
Ah doh - I thought it was catching it returning a boolean. I'll fix and resubmit. Chris - Original Message - From: Joe Conway [EMAIL PROTECTED] To: Christopher Kings-Lynne [EMAIL PROTECTED] Cc: Hackers [EMAIL PROTECTED] Sent: Friday, August 09, 2002 11:26 PM Subject: Re: [HACKERS] pg_stat_reset() weirdness Christopher Kings-Lynne wrote: Hi guys, If you apply the pg_stat_reset() function patch you get this regression failure. Is this because it's returning a bool I guess? Shall I just fix the regression test to exclude this function? AND p1.proname != 'update_pg_pwd_and_pg_group'; oid |proname ! --+--- ! 2249 | pg_stat_reset ! (1 row) Likely because this is now in CVS: DATA(insert OID = 2249 ( recordPGNSP PGUID 4 t p t \054 0 0 oidin oidout i p f 0 -1 0 _null_ _null_ )); #define RECORDOID 2249 The Oids conflict. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_stat_reset() weirdness
Christopher Kings-Lynne [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] pg_stat_reset() weirdness
Joe Conway [EMAIL PROTECTED] writes: 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. Right, we do still insist that all hand-assigned OIDs be distinct, but that is a matter of bookkeeping simplicity and possible debugging advantage. The system should only care that the OIDs in any one catalog are unique. (If it were to assume more, we'd have trouble after OID wraparound, because we can't guarantee database-wide uniqueness then. We *can* guarantee per-table uniqueness, by means of unique indexes placed on OIDs --- you'll notice all the catalogs that use OIDs have such indexes.) Actually, I don't see the regression failure here at all, now that I try the patch. Hmm. Maybe Chris just needs a make clean/rebuild/etc? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] pg_stat_reset() weirdness
Christopher Kings-Lynne [EMAIL PROTECTED] writes: If you apply the pg_stat_reset() function patch you get this regression failure. Is this because it's returning a bool I guess? Shall I just fix the regression test to exclude this function? No, you should fix the function definition. The sanity checks are there for a reason. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
