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 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

In response to

Browse pgsql-hackers by date

  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