Port Bug Report: Cache lookup Failure - Mailing list pgsql-ports

============================================================================
                        POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name        : Brian Bradley
Your email address    : bwb@netwolves.com or bbradle2@rr.tampabay.com

Category        : runtime: back-end
Severity        : critical

Summary: Cache lookup Failure

System Configuration
--------------------
  Operating System   : FreeBSD 2.2.8

  PostgreSQL version : 6.4.2

  Compiler used      : gcc version 2.7.2.1

Hardware:
---------
cyrix 200, 32M RAM, FreeBSD 2.2.8-RELEASE

Versions of other tools:
------------------------
gmake = GNU Make version 3.77
flex = flex version 2.5.4
bison = GNU Bison version 1.25

--------------------------------------------------------------------------

Problem Description:
--------------------
Situation :

whenever I try to update or delete a row int the users table I get the error message

info fmgr : cache lookup failure.

update users set username = 'new' where username = 'old';
or
delete from users where username = 'old';

I can do selects with no problems at all.

TABLES:
create table users(username varchar(20) primary key,
                   last_name varchar(50),
                   first_name varchar(50),
                   password varchar(20),
                   email_on int4,
                   fs_on int4,
                   web_access_on int4,
                   comments text,
                   email_alias varchar(50),
                   email_forward varchar(50),
                   qouta int4,
                   date_created datetime);

create table user_groups(username varchar(20),
                         group_name varchar(20));

TRIGGERS:
CREATE TRIGGER users_for_key
        BEFORE DELETE OR UPDATE ON users
        FOR EACH ROW
        EXECUTE PROCEDURE check_foreign_key(1, 'cascade', 'username', 'user_groups', 'username');

CREATE TRIGGER users_user_groups_pri_key
        BEFORE INSERT OR UPDATE ON user_groups
        FOR EACH ROW
        EXECUTE PROCEDURE check_primary_key('username', 'users', 'username');

I am using the supplied refint.so stored procedure module.

After I rebuild the whole database this problem seems to disappear, but, will eventually reappear after a few hours. I
willthen have to rebuild again. 

Rebuilding the database is not an acceptable work around nor fix.

Could someone please lead me in the right direction ?

Thanks,
Brian Bradley


--------------------------------------------------------------------------

Test Case:
----------
Situation :

whenever I try to update or delete a row int the users table I get the error message

info fmgr : cache lookup failure.

update users set username = 'new' where username = 'old';
or
delete from users where username = 'old';

I can do selects with no problems at all.

TABLES:
create table users(username varchar(20) primary key,
                   last_name varchar(50),
                   first_name varchar(50),
                   password varchar(20),
                   email_on int4,
                   fs_on int4,
                   web_access_on int4,
                   comments text,
                   email_alias varchar(50),
                   email_forward varchar(50),
                   qouta int4,
                   date_created datetime);

create table user_groups(username varchar(20),
                         group_name varchar(20));

TRIGGERS:
CREATE TRIGGER users_for_key
        BEFORE DELETE OR UPDATE ON users
        FOR EACH ROW
        EXECUTE PROCEDURE check_foreign_key(1, 'cascade', 'username', 'user_groups', 'username');

CREATE TRIGGER users_user_groups_pri_key
        BEFORE INSERT OR UPDATE ON user_groups
        FOR EACH ROW
        EXECUTE PROCEDURE check_primary_key('username', 'users', 'username');

I am using the supplied refint.so stored procedure module.

After I rebuild the whole database this problem seems to disappear, but, will eventually reappear after a few hours. I
willthen have to rebuild again. 

Rebuilding the database is not an acceptable work around nor fix.

Could someone please lead me in the right direction ?

Thanks,
Brian Bradley


--------------------------------------------------------------------------

Solution:
---------


--------------------------------------------------------------------------