> 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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
