Re: RelationFlushRelation() or RelationClearRelation()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brent Verner <brent(at)rcfile(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: RelationFlushRelation() or RelationClearRelation()
Date: 2001-11-06 23:50:08
Message-ID: 2271.1005090608@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Brent Verner <brent(at)rcfile(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-11-07 00:08:28 Re: RelationFlushRelation() or RelationClearRelation()
Previous Message g.p.ciceri 2001-11-06 23:39:28 GSL (GNU Scientific library, numerical routines) interface as a contributed module: pg-GSL.0.0.0