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 15:05:53 |
Message-ID: | 199905281505.LAA24155@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I'm pretty sure I recall a discussion to the effect that CREATE TABLE
> was failing in this case because pgsql/data/base/dbname/bug1 had already
> been created and wasn't deleted at transaction abort. That may have
> been the case in older versions of Postgres, but we seem to have fixed
> that problem: with current sources the database file *is* removed at
> transaction abort. Unfortunately the bug still persists :-(.
>
> Some quick tracing indicates that the reason the second CREATE TABLE
> fails is that there's still an entry for bug1 in the system cache: the
> search in RelnameFindRelid(),
> tuple = SearchSysCacheTuple(RELNAME,
> PointerGetDatum(relname),
> 0, 0, 0);
> is finding an entry! (If you quit the backend and start a new one,
> things go back to normal, since the new backend's relcache doesn't
> have the bogus entry.)
>
> So, apparently the real problem is that the relname cache is not cleaned
> of bogus entries inserted during a failed transaction. This strikes me
> as a fairly serious problem, especially if it applies to all the
> SysCache tables. That could lead to all kinds of erroneous behavior
> after an aborted transaction. I think this is a "must fix" issue...
OK, let me give two ideas here. First, we could create a linked list of
all cache additions that happen inside a transaction. If the
transaction aborts, we can invalidate all the cache entries in the list.
Second, we could just invalidate the entire cache on a transaction
abort. Third, we could somehow invalidate the cache on transaction
abort "only" if there was some system table modification in the
transaction. The third one seems a little harder. Because the linked
list could get large, we could do a linked list, and if it gets too
large, do an full invalidation. Also, there may be a way to spin
through the cache and remove all entries marked as part of the aborted
transaction.
Seems like this not something for 6.5.
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-05-28 15:14:36 | Development History article |
Previous Message | Tom Lane | 1999-05-28 14:22:35 | Re: [HACKERS] Open 6.5 items |