Re: RelationFlushRelation() or RelationClearRelation()

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

On 06 Nov 2001 at 19:08 (-0500), Tom Lane wrote:
| 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?

Pretty darned sure that I've accurately described my symptoms.
Doing the tgargs update before or after the actual column update
did not affect the behavior -- the cached relation->triggerdesc
still contains incorrect tgargs. I'll clean up what I have and
post a patch for review.

To reply to your earlier email asking what do I expect.

I'd like to be able to say...

brent# create table parent (id int UNIQUE);
brent# create table child (id int4 references parent(id) on update cascade);
brent# alter table parent RENAME id to hello;
brent# insert into parent values (1);
brent# insert into child values (1);

After running the above and without (re)starting a new backend yields
the following error. After getting a new backend, the behavior is as
desired.

brent=# insert into child values(1);
ERROR: constraint <unnamed>: table parent does not have an attribute id

brent=# select tgargs from pg_trigger;
tgargs
----------------------------------------------------------------

<unnamed>\000child\000parent\000UNSPECIFIED\000id\000hello\000
<unnamed>\000child\000parent\000UNSPECIFIED\000id\000hello\000
<unnamed>\000child\000parent\000UNSPECIFIED\000id\000hello\000

Your comments on this matter have been much appreciated. I'll next
look (further) into the sinval mechanism for a way to forcibly
invalidate the cached relation->triggerdesc.

Brent

--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-11-07 04:41:38 Re: pgsql/src/backend/postmaster postmaster.c
Previous Message Christopher Kings-Lynne 2001-11-07 04:37:15 Re: Status of 7.2