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?

Chris

*** ./expected/opr_sanity.out   Fri Jul 19 07:11:32 2002
--- ./results/opr_sanity.out    Fri Aug  9 13:26:00 2002
***************
*** 27,34 ****
        AND p1.proname !~ 'costestimate$'
        AND p1.proname != 'update_pg_pwd_and_pg_group';
   oid | proname
! -----+---------
! (0 rows)

  -- Look for conflicting proc definitions (same names and input datatypes).
  -- (This test should be dead code now that we have the unique index
--- 27,35 ----
        AND p1.proname !~ 'costestimate$'
        AND p1.proname != 'update_pg_pwd_and_pg_group';
   oid  |    proname
! ------+---------------
!  2249 | pg_stat_reset
! (1 row)

  -- Look for conflicting proc definitions (same names and input datatypes).
  -- (This test should be dead code now that we have the unique index

======================================================================


Fri, 9 Aug 2002 13:49:18 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
pg_stat_reset() weirdness
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> 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

Fri, 09 Aug 2002 09:50:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 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 ( record        PGNSP 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


Fri, 09 Aug 2002 08:26:08 -0700
Joe Conway <mail@joeconway.com>
Re: 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" <tgl@sss.pgh.pa.us>
To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Cc: "Hackers" <pgsql-hackers@postgresql.org>
Sent: Friday, August 09, 2002 9:50 PM
Subject: Re: [HACKERS] pg_stat_reset() weirdness


> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> 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
>


Sat, 10 Aug 2002 17:50:39 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: 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" <mail@joeconway.com>
To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Cc: "Hackers" <pgsql-hackers@postgresql.org>
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 ( record        PGNSP 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
>


Sat, 10 Aug 2002 17:52:47 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
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$'
	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

Sat, 10 Aug 2002 09:43:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
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




Sat, 10 Aug 2002 07:46:52 -0700
Joe Conway <mail@joeconway.com>
Re: pg_stat_reset() weirdness
Joe Conway <mail@joeconway.com> 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

Sat, 10 Aug 2002 11:21:54 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_stat_reset() weirdness 
> Joe Conway <mail@joeconway.com> 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



Sun, 11 Aug 2002 17:31:03 +0800 (WST)
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: 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


Sun, 11 Aug 2002 07:18:10 -0700
Joe Conway <mail@joeconway.com>
Re: 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" <mail@joeconway.com>
> To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
> Cc: "Hackers" <pgsql-hackers@postgresql.org>
> 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 ( record        PGNSP 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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 14 Aug 2002 01:17:54 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pg_stat_reset() weirdness