Horton

Thread

  1. VACUUM ANALYZE Problem

    James Hughes <jamesh@interpath.com> — 1998-02-01T13:22:02Z

    I am getting the error...

	ERROR:  fmgr_info: function 0: cache lookup failed

		...after creating a database, creating tables - indexes
and sequences, inserting data (with perl scripts) into 2 tables (570
records in one and 100 records in another), using "vacuum analyze" on
the database then trying "\d <tablename>" or "\dS". Running "vacuum"
alone is OK.

I run the query from psql.c:601 on the psql command line and get the
same result.   

I tried the same sequence with a small test database and only a few
records and there were no problems.

I am still looking into this and would appreciate any pointers.



-James

  2. Re: [HACKERS] VACUUM ANALYZE Problem

    Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-01T15:45:33Z

    James Hughes wrote:
> 
> I am getting the error...
> 
>         ERROR:  fmgr_info: function 0: cache lookup failed
> 
>                 ...after creating a database, creating tables - indexes
> and sequences, inserting data (with perl scripts) into 2 tables (570
> records in one and 100 records in another), using "vacuum analyze" on
> the database then trying "\d <tablename>" or "\dS". Running "vacuum"
> alone is OK.
> 
> I run the query from psql.c:601 on the psql command line and get the
> same result.
> 
> I tried the same sequence with a small test database and only a few
> records and there were no problems.
> 
> I am still looking into this and would appreciate any pointers.

Version ?
gdb output ?

Vadim

  3. Re: [HACKERS] VACUUM ANALYZE Problem

    James Hughes <jamesh@interpath.com> — 1998-02-01T17:41:11Z

    
On Sun, 1 Feb 1998, Vadim B. Mikheev wrote:

: James Hughes wrote:
: > 
: > I am getting the error...
: > 
: >         ERROR:  fmgr_info: function 0: cache lookup failed
: > 
: >                 ...after creating a database, creating tables - indexes
: > and sequences, inserting data (with perl scripts) into 2 tables (570
: > records in one and 100 records in another), using "vacuum analyze" on
: > the database then trying "\d <tablename>" or "\dS". Running "vacuum"
: > alone is OK.
: > 
: > I run the query from psql.c:601 on the psql command line and get the
: > same result.
: > 
: > I tried the same sequence with a small test database and only a few
: > records and there were no problems.
: > 
: > I am still looking into this and would appreciate any pointers.
: 
: Version ?

1-31 cvs tree

: gdb output ?

I'll see if I can narrow it down a bit. Might be larger than the sources
at this point ;)


-James

  4. Re: [HACKERS] VACUUM ANALYZE Problem

    James Hughes <jamesh@interpath.com> — 1998-02-03T04:17:48Z

    After poking arround some more, I found that the "vacuum analyze" is
causing problems with the "<" and ">" operators. The "> 0" in the SELECT
for "/d <table>" and "/dS" commands in psql cause the error. 

I verified that any simple query using the "<" or ">" operators fail 
with the same message...

	ERROR:  fmgr_info: function 0: cache lookup failed

 			...after using the "vacuum analyse" command.
But, only after vacuuming any relation that was created and populated by
me. Vacumming system catalogs poses no problems.

I did go back to 6.2.0. Found no problems there.


-James

  5. Re: [HACKERS] VACUUM ANALYZE Problem

    Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-03T05:09:27Z

    James Hughes wrote:
> 
> After poking arround some more, I found that the "vacuum analyze" is
> causing problems with the "<" and ">" operators. The "> 0" in the SELECT
> for "/d <table>" and "/dS" commands in psql cause the error.
> 
> I verified that any simple query using the "<" or ">" operators fail
> with the same message...

Analyze uses oper("=",...), oper("<",...) and oper(">",...)...
Are queries with "=" OK ?

> 
>         ERROR:  fmgr_info: function 0: cache lookup failed
> 
>                         ...after using the "vacuum analyse" command.
> But, only after vacuuming any relation that was created and populated by
> me. Vacumming system catalogs poses no problems.

There are comments into vc_updstats:

    /*
     * invalidating system relations confuses the function cache of
     * pg_operator and pg_opclass
     */
    if (!IsSystemRelationName(pgcform->relname.data))
        RelationInvalidateHeapTuple(rd, rtup);

==> invalidation of user relation causes problems too, Bruce ?

Vadim

  6. Re: [HACKERS] VACUUM ANALYZE Problem

    James Hughes <jamesh@interpath.com> — 1998-02-03T11:02:25Z

    
On Tue, 3 Feb 1998, Vadim B. Mikheev wrote:

: James Hughes wrote:
: > 
: > After poking arround some more, I found that the "vacuum analyze" is
: > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
: > for "/d <table>" and "/dS" commands in psql cause the error.
: > 
: > I verified that any simple query using the "<" or ">" operators fail
: > with the same message...
: 
: Analyze uses oper("=",...), oper("<",...) and oper(">",...)...
: Are queries with "=" OK ?
:

Yes...

	"=" is OK,
	"<>" is OK,
	"<" is broken,
	">" is broken,
	"<=" is broken,
	">=" is broken

		...maybe others, I have no geometrical tables to test
with. I could use some of the code from the regression tests if needed.



-James

  7. Re: [HACKERS] VACUUM ANALYZE Problem

    Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-03T11:09:07Z

    James Hughes wrote:
> 
> After poking arround some more, I found that the "vacuum analyze" is
> causing problems with the "<" and ">" operators. The "> 0" in the SELECT
> for "/d <table>" and "/dS" commands in psql cause the error.
> 
> I verified that any simple query using the "<" or ">" operators fail
> with the same message...
> 
>         ERROR:  fmgr_info: function 0: cache lookup failed
> 
>                         ...after using the "vacuum analyse" command.
> But, only after vacuuming any relation that was created and populated by
> me. Vacumming system catalogs poses no problems.

Well, I found that this problem was caused by selfuncs.c:gethilokey():

    static ScanKeyData key[3] = {
        {0, Anum_pg_statistic_starelid, F_OIDEQ},
        {0, Anum_pg_statistic_staattnum, F_INT2EQ},
        {0, Anum_pg_statistic_staop, F_OIDEQ}

: skankeys are hardcoded without call to ScanKeyEntryInitialize() =>
without initialization of sk_func.fn_oid required, I assume, by
new PL support code. Patch for this place follows...
One should check all places where ScanKeyData is used.
Jan, could you do this ?

(Oh, hell! I got this ERROR while testing subselect and spent so many time
to fix this problem...)

Vadim

  8. Re: [HACKERS] VACUUM ANALYZE Problem

    James Hughes <jamesh@interpath.com> — 1998-02-03T14:32:59Z

    
On Tue, 3 Feb 1998, Vadim B. Mikheev wrote:

: James Hughes wrote:
: > 
: > After poking arround some more, I found that the "vacuum analyze" is
: > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
: > for "/d <table>" and "/dS" commands in psql cause the error.
: > 
: > I verified that any simple query using the "<" or ">" operators fail
: > with the same message...
: > 
: >         ERROR:  fmgr_info: function 0: cache lookup failed
: > 
: >                         ...after using the "vacuum analyse" command.
: > But, only after vacuuming any relation that was created and populated by
: > me. Vacumming system catalogs poses no problems.
: 
: Well, I found that this problem was caused by selfuncs.c:gethilokey():
: 
:     static ScanKeyData key[3] = {
:         {0, Anum_pg_statistic_starelid, F_OIDEQ},
:         {0, Anum_pg_statistic_staattnum, F_INT2EQ},
:         {0, Anum_pg_statistic_staop, F_OIDEQ}
: 
: : skankeys are hardcoded without call to ScanKeyEntryInitialize() =>
: without initialization of sk_func.fn_oid required, I assume, by
: new PL support code. Patch for this place follows...
: One should check all places where ScanKeyData is used.
: Jan, could you do this ?
: 

THANKS! I'll patch my code and check the other instances.



: (Oh, hell! I got this ERROR while testing subselect and spent so many time
: to fix this problem...)
: 
: Vadim



-James

  9. Re: [HACKERS] VACUUM ANALYZE Problem

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-03T19:25:56Z

    > 
> 
> After poking arround some more, I found that the "vacuum analyze" is
> causing problems with the "<" and ">" operators. The "> 0" in the SELECT
> for "/d <table>" and "/dS" commands in psql cause the error. 
> 
> I verified that any simple query using the "<" or ">" operators fail 
> with the same message...
> 
> 	ERROR:  fmgr_info: function 0: cache lookup failed
> 
>  			...after using the "vacuum analyse" command.
> But, only after vacuuming any relation that was created and populated by
> me. Vacumming system catalogs poses no problems.
> 
> I did go back to 6.2.0. Found no problems there.

Glad it wasn't my vacuum code.  Lots of bad scan initializations.  Who
is working on that?  I think someone volunteered.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

  10. Re: [HACKERS] VACUUM ANALYZE Problem

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-03T19:26:13Z

    > 
> James Hughes wrote:
> > 
> > After poking arround some more, I found that the "vacuum analyze" is
> > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
> > for "/d <table>" and "/dS" commands in psql cause the error.
> > 
> > I verified that any simple query using the "<" or ">" operators fail
> > with the same message...
> 
> Analyze uses oper("=",...), oper("<",...) and oper(">",...)...
> Are queries with "=" OK ?
> 
> > 
> >         ERROR:  fmgr_info: function 0: cache lookup failed
> > 
> >                         ...after using the "vacuum analyse" command.
> > But, only after vacuuming any relation that was created and populated by
> > me. Vacumming system catalogs poses no problems.
> 
> There are comments into vc_updstats:
> 
>     /*
>      * invalidating system relations confuses the function cache of
>      * pg_operator and pg_opclass
>      */
>     if (!IsSystemRelationName(pgcform->relname.data))
>         RelationInvalidateHeapTuple(rd, rtup);
> 
> ==> invalidation of user relation causes problems too, Bruce ?

So this is not a problem?  right?

-- 
Bruce Momjian
maillist@candle.pha.pa.us

  11. Re: [HACKERS] VACUUM ANALYZE Problem

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-03T19:28:26Z

    > 
> 
> 
> On Tue, 3 Feb 1998, Vadim B. Mikheev wrote:
> 
> : James Hughes wrote:
> : > 
> : > After poking arround some more, I found that the "vacuum analyze" is
> : > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
> : > for "/d <table>" and "/dS" commands in psql cause the error.
> : > 
> : > I verified that any simple query using the "<" or ">" operators fail
> : > with the same message...
> : > 
> : >         ERROR:  fmgr_info: function 0: cache lookup failed
> : > 
> : >                         ...after using the "vacuum analyse" command.
> : > But, only after vacuuming any relation that was created and populated by
> : > me. Vacumming system catalogs poses no problems.
> : 
> : Well, I found that this problem was caused by selfuncs.c:gethilokey():
> : 
> :     static ScanKeyData key[3] = {
> :         {0, Anum_pg_statistic_starelid, F_OIDEQ},
> :         {0, Anum_pg_statistic_staattnum, F_INT2EQ},
> :         {0, Anum_pg_statistic_staop, F_OIDEQ}
> : 
> : : skankeys are hardcoded without call to ScanKeyEntryInitialize() =>
> : without initialization of sk_func.fn_oid required, I assume, by
> : new PL support code. Patch for this place follows...
> : One should check all places where ScanKeyData is used.
> : Jan, could you do this ?
> : 
> 
> THANKS! I'll patch my code and check the other instances.

James, are you going to submit a patch for all the source code?

-- 
Bruce Momjian
maillist@candle.pha.pa.us

  12. Re: [HACKERS] VACUUM ANALYZE Problem

    James Hughes <jamesh@interpath.com> — 1998-02-03T20:36:46Z

    
On Tue, 3 Feb 1998, Bruce Momjian wrote:

: > 
: > 
: > 
: > On Tue, 3 Feb 1998, Vadim B. Mikheev wrote:
: > 
: > : James Hughes wrote:
: > : > 
: > : > After poking arround some more, I found that the "vacuum analyze" is
: > : > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
: > : > for "/d <table>" and "/dS" commands in psql cause the error.
: > : > 
: > : > I verified that any simple query using the "<" or ">" operators fail
: > : > with the same message...
: > : > 
: > : >         ERROR:  fmgr_info: function 0: cache lookup failed
: > : > 
: > : >                         ...after using the "vacuum analyse" command.
: > : > But, only after vacuuming any relation that was created and populated by
: > : > me. Vacumming system catalogs poses no problems.
: > : 
: > : Well, I found that this problem was caused by selfuncs.c:gethilokey():
: > : 
: > :     static ScanKeyData key[3] = {
: > :         {0, Anum_pg_statistic_starelid, F_OIDEQ},
: > :         {0, Anum_pg_statistic_staattnum, F_INT2EQ},
: > :         {0, Anum_pg_statistic_staop, F_OIDEQ}
: > : 
: > : : skankeys are hardcoded without call to ScanKeyEntryInitialize() =>
: > : without initialization of sk_func.fn_oid required, I assume, by
: > : new PL support code. Patch for this place follows...
: > : One should check all places where ScanKeyData is used.
: > : Jan, could you do this ?
: > : 
: > 
: > THANKS! I'll patch my code and check the other instances.
: 
: James, are you going to submit a patch for all the source code?
: 

Go ahead with just Vadim's patch for now. It fixes the analyze problem. 
I am going out of town for a few days and won't have access to my Dev
System until then. I'll work on it this weekend if it still needs doing.



-James

  13. Re: [HACKERS] VACUUM ANALYZE Problem

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-05T04:27:10Z

    OK, I have looked at this, but can't figure out how to fix the many
initializations of ScanKeyData.  Can someone who understands this please
submit a patch for all these initializations so we can stop these vacuum
analyze reports?

Vadim has found the problem, but we need someone to properly fix it.

> James Hughes wrote:
> > 
> > After poking arround some more, I found that the "vacuum analyze" is
> > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
> > for "/d <table>" and "/dS" commands in psql cause the error.
> > 
> > I verified that any simple query using the "<" or ">" operators fail
> > with the same message...
> > 
> >         ERROR:  fmgr_info: function 0: cache lookup failed
> > 
> >                         ...after using the "vacuum analyse" command.
> > But, only after vacuuming any relation that was created and populated by
> > me. Vacumming system catalogs poses no problems.
> 
> Well, I found that this problem was caused by selfuncs.c:gethilokey():
> 
>     static ScanKeyData key[3] = {
>         {0, Anum_pg_statistic_starelid, F_OIDEQ},
>         {0, Anum_pg_statistic_staattnum, F_INT2EQ},
>         {0, Anum_pg_statistic_staop, F_OIDEQ}
> 
> : skankeys are hardcoded without call to ScanKeyEntryInitialize() =>
> without initialization of sk_func.fn_oid required, I assume, by
> new PL support code. Patch for this place follows...
> One should check all places where ScanKeyData is used.
> Jan, could you do this ?
> 
> (Oh, hell! I got this ERROR while testing subselect and spent so many time
> to fix this problem...)
> 
> Vadim
> --------------A99EE0A2D8F4D665C5BF3957
> Content-Type: application/octet-stream; name="FFF"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="FFF"
> 
> KioqIHNlbGZ1bmNzLmN+CU1vbiBGZWIgIDIgMTM6NTU6NDcgMTk5OAotLS0gc2VsZnVuY3Mu
> YwlUdWUgRmViICAzIDE3OjM2OjAxIDE5OTgKKioqKioqKioqKioqKioqCioqKiAzMzcsMzQ1
> ICoqKioKICAJcmVnaXN0ZXIgUmVsYXRpb24gcmRlc2M7CiAgCXJlZ2lzdGVyIEhlYXBTY2Fu
> RGVzYyBzZGVzYzsKICAJc3RhdGljIFNjYW5LZXlEYXRhIGtleVszXSA9IHsKISAJCXswLCBB
> bnVtX3BnX3N0YXRpc3RpY19zdGFyZWxpZCwgRl9PSURFUX0sCiEgCQl7MCwgQW51bV9wZ19z
> dGF0aXN0aWNfc3RhYXR0bnVtLCBGX0lOVDJFUX0sCiEgCQl7MCwgQW51bV9wZ19zdGF0aXN0
> aWNfc3Rhb3AsIEZfT0lERVF9CiAgCX07CiAgCWJvb2wJCWlzbnVsbDsKICAJSGVhcFR1cGxl
> CXR1cGxlOwotLS0gMzM3LDM0NSAtLS0tCiAgCXJlZ2lzdGVyIFJlbGF0aW9uIHJkZXNjOwog
> IAlyZWdpc3RlciBIZWFwU2NhbkRlc2Mgc2Rlc2M7CiAgCXN0YXRpYyBTY2FuS2V5RGF0YSBr
> ZXlbM10gPSB7CiEgCQl7MCwgQW51bV9wZ19zdGF0aXN0aWNfc3RhcmVsaWQsIEZfT0lERVEs
> IHswLCAwLCBGX09JREVRfX0sCiEgCQl7MCwgQW51bV9wZ19zdGF0aXN0aWNfc3RhYXR0bnVt
> LCBGX0lOVDJFUSwgezAsIDAsIEZfSU5UMkVRfX0sCiEgCQl7MCwgQW51bV9wZ19zdGF0aXN0
> aWNfc3Rhb3AsIEZfT0lERVEsIHswLCAwLCBGX09JREVRfX0KICAJfTsKICAJYm9vbAkJaXNu
> dWxsOwogIAlIZWFwVHVwbGUJdHVwbGU7Cg==
> --------------A99EE0A2D8F4D665C5BF3957--
> 
> 


-- 
Bruce Momjian
maillist@candle.pha.pa.us

  14. Re: [HACKERS] VACUUM ANALYZE Problem

    Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-05T04:58:15Z

    Bruce Momjian wrote:
> 
> OK, I have looked at this, but can't figure out how to fix the many
> initializations of ScanKeyData.  Can someone who understands this please
> submit a patch for all these initializations so we can stop these vacuum
> analyze reports?
> 
> Vadim has found the problem, but we need someone to properly fix it.

Just apply my patch to stop "analyze-problem" reports (sorry, I didn't it).
As for other (possible) places, note that ScanKeyEntryInitialize()
initializes sk_func.fn_oid and so we have to worry about hard-coded
initializations only (when ScanKeyEntryInitialize() is not called).

Vadim

  15. Re: [HACKERS] VACUUM ANALYZE Problem

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-16T04:40:48Z

    > 
> This is a multi-part message in MIME format.
> --------------A99EE0A2D8F4D665C5BF3957
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> James Hughes wrote:
> > 
> > After poking arround some more, I found that the "vacuum analyze" is
> > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
> > for "/d <table>" and "/dS" commands in psql cause the error.
> > 
> > I verified that any simple query using the "<" or ">" operators fail
> > with the same message...
> > 
> >         ERROR:  fmgr_info: function 0: cache lookup failed
> > 
> >                         ...after using the "vacuum analyse" command.
> > But, only after vacuuming any relation that was created and populated by
> > me. Vacumming system catalogs poses no problems.
> 
> Well, I found that this problem was caused by selfuncs.c:gethilokey():
> 
>     static ScanKeyData key[3] = {
>         {0, Anum_pg_statistic_starelid, F_OIDEQ},
>         {0, Anum_pg_statistic_staattnum, F_INT2EQ},
>         {0, Anum_pg_statistic_staop, F_OIDEQ}
> 
> : skankeys are hardcoded without call to ScanKeyEntryInitialize() =>
> without initialization of sk_func.fn_oid required, I assume, by
> new PL support code. Patch for this place follows...
> One should check all places where ScanKeyData is used.
> Jan, could you do this ?
> 
> (Oh, hell! I got this ERROR while testing subselect and spent so many time
> to fix this problem...)

I assume we can consider this item closed.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

  16. Re: [HACKERS] VACUUM ANALYZE Problem

    James Hughes <jamesh@interpath.com> — 1998-03-20T02:17:36Z

    
On Sun, 15 Mar 1998, Bruce Momjian wrote:

: > 
: > This is a multi-part message in MIME format.
: > --------------A99EE0A2D8F4D665C5BF3957
: > Content-Type: text/plain; charset=us-ascii
: > Content-Transfer-Encoding: 7bit
: > 
: > James Hughes wrote:
: > > 
: > > After poking arround some more, I found that the "vacuum analyze" is
: > > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
: > > for "/d <table>" and "/dS" commands in psql cause the error.
: > > 
: > > I verified that any simple query using the "<" or ">" operators fail
: > > with the same message...
: > > 
: > >         ERROR:  fmgr_info: function 0: cache lookup failed
: > > 
: > >                         ...after using the "vacuum analyse" command.
: > > But, only after vacuuming any relation that was created and populated by
: > > me. Vacumming system catalogs poses no problems.
: > 
: > Well, I found that this problem was caused by selfuncs.c:gethilokey():
: > 
: >     static ScanKeyData key[3] = {
: >         {0, Anum_pg_statistic_starelid, F_OIDEQ},
: >         {0, Anum_pg_statistic_staattnum, F_INT2EQ},
: >         {0, Anum_pg_statistic_staop, F_OIDEQ}
: > 
: > : skankeys are hardcoded without call to ScanKeyEntryInitialize() =>
: > without initialization of sk_func.fn_oid required, I assume, by
: > new PL support code. Patch for this place follows...
: > One should check all places where ScanKeyData is used.
: > Jan, could you do this ?
: > 
: > (Oh, hell! I got this ERROR while testing subselect and spent so many time
: > to fix this problem...)
: 
: I assume we can consider this item closed.
: 

The problem on my system was fixed by the patch. 


-James