Thread: Re: [HACKERS] 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. > 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: > 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 certainly didn't happen very consistently, in fact, only once. On Fri, 13 March 1998, at 19:43:48, Jan Wieck wrote: > 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