suspected problem with cache updates

I've noticed recently that after making certain changes to the
database (adding indices, attributes) they aren't immediately known
about. for example, I add an attribute, then try to update that
attribute it tells me it doesn't exist. if I exist psql and start a
new connection all is well. but it doesn't happen consistently..

Looks like problems in the syscache/catcache invalidation
routines.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

I've noticed recently that after making certain changes to the
database (adding indices, attributes) they aren't immediately known
about. for example, I add an attribute, then try to update that
attribute it tells me it doesn't exist. if I exist psql and start a
new connection all is well. but it doesn't happen consistently..

Looks like problems in the syscache/catcache invalidation
routines.

This existed in an older version, but I could almost swear that someone
fixed it.

Bruce, do you have old versions of the TODO lists around to check on
this one? I specifically remember the part about adding an attribute
and it not being there until the next session.

darrenk

Darren wrote:

I've noticed recently that after making certain changes to the
database (adding indices, attributes) they aren't immediately known
about. for example, I add an attribute, then try to update that
attribute it tells me it doesn't exist. if I exist psql and start a
new connection all is well. but it doesn't happen consistently..

Looks like problems in the syscache/catcache invalidation
routines.

This existed in an older version, but I could almost swear that someone
fixed it.

I fixed something there lately when it came to pg_shadow,
where the required update on pg_class during revoke/grant
just outdated the syscache tuple for pg_shadow, but the
permission checking code needed that.

But this problem looks different. This time the pg_class
tuple for a user table is updated where that table had to be
flushed from the relcache and reopened. Cannot reproduce the
error here. If I alter table add field, they show up
immediately in the same session.

Bruce, do you have old versions of the TODO lists around to check on
this one? I specifically remember the part about adding an attribute
and it not being there until the next session.

darrenk

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

This existed in an older version, but I could almost swear that someone
fixed it.

Bruce, do you have old versions of the TODO lists around to check on
this one? I specifically remember the part about adding an attribute
and it not being there until the next session.

I think that was a very old bug. It involved ALTER TABLE ADD and the
thing not appearing until the next session, I think. It has to do with
the attribute cache. The only old TODO versions I have are in the old
releases.

-- 
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)

It must be reappearing again. It happened under 6.3

On Fri, 13 March 1998, at 17:20:52, Bruce Momjian wrote:

It certainly didn't happen very consistently, in fact, only once.

On Fri, 13 March 1998, at 19:43:48, Jan Wieck wrote: