From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brent Verner <brent(at)rcfile(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RelationFlushRelation() or RelationClearRelation() |
Date: | 2001-11-07 00:08:28 |
Message-ID: | 2363.1005091708@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I said:
> 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.
It sure looks to me like the update of the pg_attribute row
should be sufficient to queue a relcache flush message (see
RelationInvalidateHeapTuple and subsidiary routines in
backend/utils/cache/inval.c). We could argue about whether
PrepareForTupleInvalidation needs to test for a wider variety of
relcache-invalidating updates, but nonetheless I don't see why
renameatt would be failing to trigger one. Are you sure it's
not working?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-11-07 01:07:49 | Re: Proposal: 7.2b2 today |
Previous Message | Tom Lane | 2001-11-06 23:50:08 | Re: RelationFlushRelation() or RelationClearRelation() |