Re: RelationFlushRelation() or RelationClearRelation()
От | Tom Lane |
---|---|
Тема | Re: RelationFlushRelation() or RelationClearRelation() |
Дата | |
Msg-id | 2271.1005090608@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: RelationFlushRelation() or RelationClearRelation() (Brent Verner <brent@rcfile.org>) |
Ответы |
Re: RelationFlushRelation() or RelationClearRelation()
|
Список | pgsql-hackers |
Brent Verner <brent@rcfile.org> writes: > It is probably noteworthy that I am directly modifying the tgargs > in the pg_trigger table, via simple_heap_update(). This modfication > is made at the end of renameatt() in rename. Seems reasonable. Now that I think about it, the problem is almost certainly that the relcache+sinval mechanism isn't recognizing this update as requiring relcache-entry rebuild. If you update a pg_class row, it definitely does recognize that event as forcing relcache rebuild, and I had thought that updating a pg_attribute row associated with a relcache entry would cause one too. But maybe not. We should either extend the sinval code to make that happen, or tweak renameatt to force a relcache flush explicitly. Alternatively, maybe you're expecting too much? The relcache rebuild doesn't (and isn't supposed to) happen until the next transaction commit or CommandCounterIncrement. If you've structured the code in a way that needs the relcache change to happen sooner, then I think we need to find a way to avoid expecting that to happen. > Also, is directly updating the pg_trigger table advisable? simple_heap_update seems pretty direct to me :-) ... what did you have in mind? regards, tom lane
В списке pgsql-hackers по дате отправления: