Re: It's past time to redo the smgr API

On Thu, Feb 05, 2004 at 02:05:46PM -0500, Tom Lane wrote:

> * smgrclose closes the md.c-level file and drops the hashtable entry.
> Hashtable entries remain valid unless explicitly closed (thus, multiple
> smgropens for the same file are legal).

So, will there be a refcount on each cache entry? Else, how would
smgrclose when to drop the cache entry if there had been multiple
smgropen calls to the same file? (unless, of course, each smgropen call
yields a different hash entry?)

> I'm also thinking of merging smgr.c's existing
> list-of-rels-to-be-deleted into this data structure.

Please don't. In the nested transaction environment, each subxact has
to keep track of which files should be deleted. That's why I was trying
to set the list inside a transaction status stack.

Another way to do it would be keeping the list of files to delete along
with the deleting Xid, but that would also require keeping a list of
which xacts aborted and which ones didn't.

> * AFAICS the only downside of not having a Relation available in smgr.c
> and md.c is that error messages could only refer to the RelFileNode
> numbers and not to the relation name. I'm not sure this is bad, since
> in my experience what you want to know about such errors is the actual
> disk filename, which RelFileNode tells you and relation name doesn't.

I agree it's best to have the filename in the error message, but IMHO
the relation name should also be presented to the user for clarity.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Endurecerse, pero jamás perder la ternura" (E. Guevara)