From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)atentus(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: CLUSTER patch |
Date: | 2002-07-14 17:21:00 |
Message-ID: | 200207141721.g6EHL0S09573@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > + CommandCounterIncrement();
> > +
> > + // bjm
> > + // RelationIdInvalidateRelationCacheByRelationId(r1);
> > + // RelationIdInvalidateRelationCacheByRelationId(r2);
> > +
> > + RelationClearRelation(RelationIdGetRelation(r1), true);
> > + // RelationClearRelation(RelationIdGetRelation(r2), true);
> > +
> > + CommandCounterIncrement();
>
> Surely the above is neither necessary nor appropriate. The relcache
> should automatically rebuild its entries for these relations at
New patch attached. Something like this is required or
heap_drop/index_drop will fail because it can't find the relation cache
entries for the relation. Maybe the trick is to properly invalidate the
relation caches when pg_class is updated. This is particularly
significant for thisxactonly relations. I don't think we need to handle
oid changes in pg_class, but relfilenode changes are not updated,
causing problems down the road. The attached patch actually does work
with the following warnings:
test=> cluster i on test;
WARNING: trying to delete a reldesc (rd_node) that does not exist.
WARNING: trying to delete a reldesc (rd_node) that does not exist.
CLUSTER
My guess is that the proper fix is elsewhere. I looked through
relcache.c and didn't see any case where a relfilenode could be
invalidated _without_ removing the old entry first, but of course, the
old entry has a different value from the new one. My guess is that the
work is to be done there somewhere.
My cache forget calls work because it forces new cache entries to match
pg_class, and that way the other commands can succeed.
> CommandCounterIncrement. In any case I do not care for exporting
> internal relcache routines to make CLUSTER work ...
I need to get cluster working before I can worry about style.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/plain | 18.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-07-14 17:28:09 | Re: CLUSTER patch |
Previous Message | Tom Lane | 2002-07-14 17:03:02 | Re: CLUSTER patch |