Re: [HACKERS] Ye olde "relation doesn't quite exist" problem

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Ye olde "relation doesn't quite exist" problem
Date: 1999-05-28 18:41:13
Message-ID: 199905281841.OAA00257@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Is there room in the SysCaches for the transaction ID of the last
> transaction to modify each entry? That would provide an easy and
> inexpensive way of finding the ones to zap when the current xact is
> aborted, I would think: abort would just scan all the caches looking
> for entries with the current xact ID, and invalidate only those entries.
> The cost in the no-error case would just be storing an additional
> field whenever an entry is modified; seems cheap enough. However,
> if there are a lot of different places in the code that can create/
> modify a cache entry, this could be a fair amount of work (and it'd
> carry the risk of missing some places...).

Yes, I think we could put it in, though it may have to sequential scan
to remove the entries.

>
> > Seems like this not something for 6.5.
>
> I think we really ought to do *something*. I'd settle for the
> brute-force blow-away-all-the-caches answer for now, though.

OK. I wonder if there are any problems with that. I do that in heap.c:

/*
* This is heavy-handed, but appears necessary bjm 1999/02/01
* SystemCacheRelationFlushed(relid) is not enough either.
*/
RelationForgetRelation(relid);
ResetSystemCache();

as part of a temp table creation to remove any non-temp table entry in
the cache. I could not find another way, and because the temp table
creation doesn't cause problems, this could probably be used in
transaction abort too.

--
Bruce Momjian | http://www.op.net/~candle
maillist(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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 1999-05-28 21:19:36 Re: [HACKERS] Performance problem partially identified
Previous Message Tom Lane 1999-05-28 18:33:39 Re: [HACKERS] Ye olde "relation doesn't quite exist" problem