Re: [HACKERS] suspected problem with cache updates
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] suspected problem with cache updates |
Дата | |
Msg-id | m0yDZQq-000BFRC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] suspected problem with cache updates (darrenk@insightdist.com (Darren King)) |
Ответы |
Re: [HACKERS] suspected problem with cache updates
|
Список | pgsql-hackers |
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) #
В списке pgsql-hackers по дате отправления: